I have searched this site for the following, prior to posting this message:

baan iv ldap
baan iv active directory
baan iv authentication
baan iv single sign on

I get no results.

My BAAN server is HP-UX (version actually unknown)
Oracle is 9-something (version actually unknown)
BAAN IVc3

Active Directory is on Windows Server 2003 (currently in mixed mode due to a remaining NT server for some Win98 clients ... DON'T ASK!!)

Users utilize their accounts in active directory for accessing everything except BAAN.

INTRODUCTION
1. user BAAN passwords are system generated
2. at expiration, for users to change their password, they have to use a command window (of course, most users do not recognize this, and lock themselves out)
a. Can I do someting in BAAN to recognize this condition, and push the user directly into another routine/command (such as for change password script if expired, wrong username/password if it is wrong, locked out account if locked out?)
3. during initial user setup, ora8_admin6.1 is used to set up the baan userid to match with their oracle userid
4. oracle passwords and baan passwords are initially the same
5. baan passwords are configured to expire every so often, so users change the password
6. oracle password does not expire
7. users utilize applications like oracle discoverer to pull data, requiring oracle password
8. confused users invariably mix up passwords, and lock themselves out of baan (after only three attempts) admin must intervene
9. confused users forget their discoverer password, and it must be reset by an admin
10. users who want to be highly productive write down their baan/oracle passwords, so they can be sure not to screw them up or forget them!!!

what using active directory would do for us:
1. simplify authentication for the end user
2. decrease number of times a user has to change their password
3. when user comes back from a weekend and forgets their passwords, only one has to be reset, instead of two or three (you know this is true!)
4. prevent users from writing down their system-generated baan passwords, (because they can not remember them and are afraid of getting locked out for getting it wrong)
5. avoid giving users passwords that do not change (oracle) ... (we already have a means of giving users the same access as oracle discoverer, but using windows authentication, and are in the process of transitioning the discoverer .DIS files over to web-based Cyberquery)

Overall, this would probably cut help desk calls by at least 25%, and increase worker productivity (since they no longer have to wait until IT changes their password before they can get back to work) as well as the security of our ERP system.

If someone has a FREE way to do this, that would be great. If not, let me know what my options are otherwise.

Thanks!

I am also posting this question with Infor. I will post the response, if/when I receive it.

I researched something similar years ago and got it working by using CIFS/Samba in combination with PAM (Pluggable Authentication Module) of HP-Ux.

PAM allows you to tell your HP-Ux box to authenticate the unix-users against Active Directory (using Samba). This works so well, that if users changes his/her password on Unix, it actually changes the password in AD and vice versa.

To configure this, do not ask Infor, open up a support request with HP!!!

In the end, we did not go live with this configuration, because we did not want to become dependent on AD at the time, as Unix and Windows administrationw as in seperate hands.

Good luck,

Markus

P.S.: This obviously does not help you with the oracle login, but also Oracle can do windows authentification, even though the configuration of this is a competely different issue. By the way, I doubt it is a good idea to give your users the login of their oracle user. With this login/password users have full read and write access to all (!) Baan tables. Hardly something you usually want.

I researched something similar years ago and got it working by using CIFS/Samba in combination with PAM (Pluggable Authentication Module) of HP-Ux.

PAM allows you to tell your HP-Ux box to authenticate the unix-users against Active Directory (using Samba). This works so well, that if users changes his/her password on Unix, it actually changes the password in AD and vice versa.

Thanks for this tip. You have educated me. I always figured there had to be a way to do this, but couldn't put my head around it.


To configure this, do not ask Infor, open up a support request with HP!!!

Thanks. Will get right on this Monday morning when I get to the office.


In the end, we did not go live with this configuration, because we did not want to become dependent on AD at the time, as Unix and Windows administrationw as in seperate hands.

Hrm. By separate hands, do you mean different people hold the roles? This is actually no big deal to me, as we need to get our 'NIX admin better cross-trained in Windows administration anyway. (And vice-versa for our Windows admin.) This cross-platform authentication is just the type of thing we need to be doing.


Good luck,

Markus


Thanks again. You may not realize how much you are helping me, but thanks.


P.S.: This obviously does not help you with the oracle login, but also Oracle can do windows authentification, even though the configuration of this is a competely different issue.

Yes, we do use Oracle with Windows authentication, for a reporting tool that we use called Cyberquery.


By the way, I doubt it is a good idea to give your users the login of their oracle user. With this login/password users have full read and write access to all (!) Baan tables. Hardly something you usually want.

I am trying to understand the logic .... hold up ... I think a light is coming on ...

Are you basically saying that this is what actually happens (regardless of how I have the security set-up in enterprise manager) ....

oracle user - read/write perms
baan user - read/write perms based on permissions assigned within baan

result:
baan user login = gets perms based on their assigned access rights within baan application
oracle user login = gets read/write perms and ability to modify all tables?

My concern was the fact that the password wasn't changing. You now open my eyes to a bigger potential problem of users wreaking complete havoc on the system. [Just was looking throught Enterprise Manager, and saw the password expiration section .... but based on our set-up, would be foolhardy to break the user's access to the database ... when the average user never knows their true oracle login .... which is actually how it should be, and how I would prefer it.]

The way I see the users setup in the Oracle Enterprise Manager, the oracle logins have to be given permission to do certain functions. If they are not assigned the permissions, then they can't do it, right?

So, my question is ... how does this work, that the oracle login can modify baan tables?

We have users setup with enterprise manager for "roles" and "system"
-- for role, we only have them for "connect" and "r_baan"
Under role selection, they only get "default" and not "admin option" selected. I would be led to believe that "admin option" would be required to modify the tables, right?

-- for system, they don't get any "system" privileges by default. There are a very select few role-based logins that have "system" privileges, from what I can see, and these logins are not used by the users.

Thanks for the tips, Markus, but I seriously need assistance with understanding the security implications for oracle logins having perms to modify baan tables, as this revelation is quite alarming.

-- for role, we only have them for "connect" and "r_baan"


Here is your major problem!! You have to understand, what is happening, when a Baan admin creates a table in Baan. In this momoment Baan connect as oracle user "baan" to the database and creates the table. So the owner in oracle is the oracle user baan. Then it grants select/update/delete/insert permissions to this new table to the role r_baan.

In effect this means, that every oracle user, who is assigned tro r_baan, can not drop a baan table, but he/she can do any other change to it. Permissions defined in DEM or any other part of Baan have no effect here.

This is normally not what you want, is it?

Regards

Markus

Here is your major problem!! You have to understand, what is happening, when a Baan admin creates a table in Baan. In this momoment Baan connect as oracle user "baan" to the database and creates the table. So the owner in oracle is the oracle user baan. Then it grants select/update/delete/insert permissions to this new table to the role r_baan.

In effect this means, that every oracle user, who is assigned tro r_baan, can not drop a baan table, but he/she can do any other change to it. Permissions defined in DEM or any other part of Baan have no effect here.

This is normally not what you want, is it?

Regards

Markus

Markus:

WOW. So users only need the "connect" role? How is it that users are obtaining this "R_BAAN" role? I do not recall every specifying it. OH wait, now let me recall the user creation script ....

When users are created initially, we do the following:

1. create unix user
useradd -g bsp -m -s /usr/bin/sh -c '%FirstName%, %Location%' %username%
passwd %username%
(kicks off into a script at this point, where it produces a random, system-generated password that must be keyed twice to take effect ... else the loop repeats until that occurs)

2. create oracle user
sqlplus
%oracle_sa_login%
%oracle_sa_password%
create user %username% identified by %password%;
grant connect to %username%;
commit;
quit

3. link baan/system to oracle user
ora8_admin6.1
Option 1 -Add User
%username% for baan username
%username% for oracle username
%password% for password
baan for Group name * <<< is this the step that is wrong? >>
%baan_password% for group password

4. copy authorizations between users
baaniv
> baaniv tools
> user management
> general user data
>maintain user data
.... copy authorizations to selected user from a template user

5. test login to baaniv

Is step 3 the bad step?

I am sorry for all the questions, but I have no BAAN background (I'm neither the developer nor the DBA) but I have to support everything, so it is important that I know these basics. (and you're quicker to reply than infor to queries)


P.S.: By the way, they (Infor) did answer my query, but basically said that PAM is what I wanted to use, but they weren't going to support it. (Did note that some customers had gotten it to work, but it was "cluuged") Said that until there was a supported way to synchronize across all databases and operating systems, then they would not support it. Did also mention that I could have a warning period before the password actually expired (which we don't currently use).

When you link the Baan user and the oracle user with the oraadmin tool, then behind the scenes, that tool is executing a "grant r_baan to <USER>".

Now this is normal and must be like this, because the baan user needs to be able to access the tables, when working in Baan.

Your problem is somewhere else: Your users should not use the same oracle user for their access via Baan and their access via a direct database query tool. The end user should not have the password of oracle for these users. Instead for direct DB access they should use a different oracle user, which only got "select" permissions on selected tables and not all permissions on all tables.

Regards

Markus

When you link the Baan user and the oracle user with the oraadmin tool, then behind the scenes, that tool is executing a "grant r_baan to <USER>".

Now this is normal and must be like this, because the baan user needs to be able to access the tables, when working in Baan.

Your problem is somewhere else: Your users should not use the same oracle user for their access via Baan and their access via a direct database query tool. The end user should not have the password of oracle for these users. Instead for direct DB access they should use a different oracle user, which only got "select" permissions on selected tables and not all permissions on all tables.

Regards

Markus

Markus:

I see the problem that you speak of now. (you say their oracle user can potentially modify anything in baan, provided that user had an interface to getting into the database to modify it)

Apparently, I thought that when the role of the user is defined, when I check in the "oracle enterprise manager console" I see that there are two options:
admin option, and "default"
From what I can determine, only the user "baan" has "admin option" under "r_baan"
every other user only has "default" under the "r_baan" role.

Now, the way that users do interface to the database under their specific oracle names is with "oracle discoverer", which they use to run queries.

They have "default" role for this, but not "admin option".

I am just trying to figure out how to repair this apparent problem that I never knew existed.

I guess it is an interesting quandary.

to make all of the baan administration mean something, you restrict the OS user, but leave the DB user unrestricted (so you can potentially grant access to things to the OS user, and control access at one point). As long as the user never knows the DB user information, everything is fine, and you can still log whatever access the user has.

I guess I need an idea of how to limit the direct oracle query access (which is what I thought the discoverer was for, as well as the "discoverer" role, as they can't even run that app without that role)

If this problem is as potentially serious as you say, we may have to discontinue usage of "discoverer" and change all of the user's oracle passwords .... provided that we can find a working solution to their ad hoc query needs.

Thanks!