Hi,

This seems to be a controversial topic ....

Imagine the scenario ... We are a typical Microsoft house running Microsoft Active Directory across multiple Microsoft domain controllers blah blah.

We're implementing Lawson version 9.0 and as part of this, the current working assumption is that we will install ADAM onto the Lawson application server as per the support notes. Instaling ADAM on the application server seems to be the best fit architecturaly since we can take the default ports, rather than installing it on a global catalogue server(domain controller) and have to install it using different ports.

Here is the problem: -

To define a user in Lawson, you use Resource Manager to create Joe Bloggs' account in ADAM, using a password of your choice. This password is then profiled etc and set up to use the Portal. However, you are also required to reference the account against an operating system account, which is a member of the local group 'lawusers' on the Lawson application server. This group has the local right to 'log on locally' and 'run as a batch job'. This is so that users can run batch jobs from with the portal and self service,etc. However, if the ADAM Joe Bloggs user account password doesn't match the operating system password for Joe Bloggs, then the job will fail to run.

This is the first part, the second problem is that we want users to be authenticated againts our own coroporate domain so that passwords etc can be defined and reset centrally, typically within our help desk.

My current thinking is that we install ADAM on the Lawson application server and configure it as per the Lawson instructions, but then configure LDAP bind to use an operating system account on our corporate domain. This user will then be put in the local group 'lawusers' on the application server, which has the relevant rights so that users can run a batch job using the same username and password. This seems to be my logical conclusion.

Questions:

If LDAP bind is used, then does the 'change password' button in the portal stop working?

Why can't the Lawson LDAP schema be created within a partition with the corporate Active Directory Schema?

How does LDAP bind work exactly?

Are there any regular syncronisation problems using LDAP bind?

I pressume ADAM needs to be backed up as part of your database backups in order to retain user and security information?

Any questions or comments?

Kind Regards,

Andy.

> If LDAP bind is used, then does the 'change password' button in the portal stop working?

Nope - LDAP bind is a not-so-simple pass thru, referring all authentication related traffic onward.

> Why can't the Lawson LDAP schema be created within a partition with the corporate Active Directory Schema?

Because the Microsoft people who worked with Lawson screamed "DON'T DO IT!!!" when asked about it. There are a huge number of changes that Lawson makes in it's LDAP repository, which would cause major issues if introduced into a corporate-wide structure

> How does LDAP bind work exactly?

Rather well.. Thanks to some brave Unix souls who know a LOT more about network protocols that I.

> Are there any regular syncronisation problems using LDAP bind?

It's not synchronized - it's pass-thru in real-time.


> I pressume ADAM needs to be backed up as part of your database backups in order to retain user and security information?

Absolutely!!

This is wonderful information.

So LDAP bind is the way to go if we want to integrate with our corporate active directory and it appears that LDAP bind gives complete authentication pass through.

I take it if this method is used, then all current users will have to be imported into ADAM? How is this done?

If new users are created after the import, I presume new users will have to be set up in AD and in ADAM?

Does anyone have any other information regarding operating system accounts and LSF, particularly around group access on the application server?