Hi all,
I have an other issue I would like to discuss with you. When you set up the repository, you should grant users for the repository database tables. If users have update rights, they can edit passwords of other users, delete universes etc. with any other tool that is able to access the database.
How did you solve this security problem?
Regards, Michiel Brunt
ABN AMRO Bank
Listserv Archives (BOB member since 2002-06-25)
In a message dated 98-12-05 09:37:11 EST, you write:
When you set up the repository, you should grant users for the repository
database tables. If users have update rights, they can edit passwords of other users, delete universes etc. with any other tool that is able to access the database.
How did you solve this security problem?
Regards, Michiel Brunt
Michiel:
I believe that all updates to the repository are done via the repository owner ID that is stored in the BOMAIN.KEY file. Thus, you should not have to grant anything to anyone on these repository tables.
This should cover exporting and importing documents as well.
I am basing this idea on the fact that I have never run in to a problem where I had to grant users rights on the repository tables. Have you run into problems? Or are you just trying to anticipate?
Also, the passwords are not really subject to being updated, as they are stored in encrypted form. If a user did have access to the tables, and attempted to reset a password via direct manipulation, it would not work. They could, however, set the password to null. I do not know if there is an encrypted version of a null (or missing) password.
Regards,
Dave Rathbun
Integra Solutions
www.islink.com
Listserv Archives (BOB member since 2002-06-25)
I did not grant any rights to the users in the first place … I’d set up the security repository under a different user schema. They do not need (and in my opinion should not have) read/write access to these tables.
Martin Lidl
Consultant
KPN-Orange
e-mail: martin.lidl@orange.be
“Normal is the average of extremes”
Michiel Brunt Michiel.Brunt@NL.ABNAMRO.COM on 04/12/98 08:36:27
Please respond to Business Objects Query Tool BUSOB-L@LISTSERV.AOL.COM
cc: (bcc: Martin Lidl/IT/Kpn-Orange)
Hi all,
I have an other issue I would like to discuss with you. When you set up the repository, you should grant users for the repository database tables. If users have update rights, they can edit passwords of other users, delete universes etc. with any other tool that is able to access the database.
How did you solve this security problem?
Regards, Michiel Brunt
ABN AMRO Bank
Listserv Archives (BOB member since 2002-06-25)
I have a problem with security and the BO repository. Our situation is as follows:
Repository: DB2 on NT
Access through one userid and password which is supplied in BOMAIN.KEY
Database: DB2 on MVS
Access through a connection with a variable userid and password (BOUSER/BOPASS)
In the repository, the password checking is turned off, so we have only one place to register passwords (just for the database) When a BO user logs on, he uses his database userid and password. In the repository, BO only checkes the userid for the profile of the user (which universes, documents are available) and uses userid and password for access to the database.
This works all fine, except for one situation: When we send a report to a user of have a document scheduled by DAS, it is stored in the repository. A user can log on to BO with the userid of his manager and leave the password blank. This works fine, because BO does not check it. The user can now access all repository and DAS document of his manager.
The solution could be to turn on the password checking in BO, but then we have a synchronising problem with BO (repository) and the database.
Can anyone help?
Regards,
Michiel Brunt
Listserv Archives (BOB member since 2002-06-25)
I have a problem with security and the BO repository. Our situation is as
follows:
Repository: DB2 on NT
Access through one userid and password which is supplied in BOMAIN.KEY
Database: DB2 on MVS
Access through a connection with a variable userid and password
(BOUSER/BOPASS)
In the repository, the password checking is turned off, so we have only
one place to register passwords (just for the database)
When a BO user logs on, he uses his database userid and password. In the
repository, BO only checkes the userid for the profile of the user (which
universes, documents are available) and uses userid and password for
access to the database.
This works all fine, except for one situation:
When we send a report to a user of have a document scheduled by DAS, it
is stored in the repository. A user can log on to BO with the userid of
his manager and leave the password blank. This works fine, because BO
does not check it. The user can now access all repository and DAS
document of his manager.
The solution could be to turn on the password checking in BO, but then we
have a synchronising problem with BO (repository) and the database.
Can anyone help?
Regards,
Michiel Brunt
Listserv Archives (BOB member since 2002-06-25)
Michiel wrote:
The solution could be to turn on the password checking in BO, but then we have a synchronising problem with BO (repository) and the database.
Turning off password checking was built into BO to make a single point of logon possible, but that doesn’t seem to be your case. The user could then never logon with a different userid because he simply doesn’t fill it in.
In your case it’s not wise to turn it off, what if someone with an evil mind gets his hands on the general manager ID?
There are two ways to go:
Either go for the single point of logon strategy completely. Use the network login for going to BO and to the database (in both password checking should now be unnecessary).
Or turn on password checking.
I understand your problem with the latter, but here is a trick that might help:
You could go for a database password that is derived from the userid. Add some character string to it that only you (and other supervisors) know. Then the BO password is strictly the BO password and the database password doesn’t have to change with it.
Good luck,
Marianne Wagt
IDETA
The Netherlands
Listserv Archives (BOB member since 2002-06-25)
Michiel wrote:
The solution could be to turn on the password checking in BO,
but then we have a synchronising problem with BO (repository) and the
database.
Turning off password checking was built into BO to make a single point
of logon possible, but that doesn’t seem to be your case. The user could
then never logon with a different userid because he simply doesn’t fill
it in.
In your case it’s not wise to turn it off, what if someone with an evil
mind gets his hands on the general manager ID?
There are two ways to go:
Either go for the single point of logon strategy completely. Use the
network login for going to BO and to the database (in both password
checking should now be unnecessary).
Or turn on password checking.
I understand your problem with the latter, but here is a trick that
might help:
You could go for a database password that is derived from the userid.
Add some character string to it that only you (and other supervisors)
know. Then the BO password is strictly the BO password and the database
password doesn’t have to change with it.
Good luck,
Marianne Wagt
IDETA
The Netherlands
Listserv Archives (BOB member since 2002-06-25)