We are in process of migrating to Lawson Security. We have thousands of users for EMSS and rather than turn over the new Lawson Security interface to all department heads we are scripting the creation, updates and deletes of users. Lawson provides the loadusers command to mass load users, but we also need the capability to script updates as well as deletes. Has anyone done this successfully? Is the only option to use ldife scripting and figure out ourselves what all containers in ADAM we will need to update and or remove?

We have changes literally daily so our security admins would not have time to run mass updates daily from within Security interface...

Thanks for any input.

George:

Here's what I can throw in. This little bit of info should NOT be considered complete or trustworthy. Check it out for yourself.

How ADAM is set up - a little bit of explanation.

This is how our ADAM looks like. We are running UNIX servers (Solaris 10) with MS-ADAM running on a Windows XP Professional box (actually, a virtual PC running on a blade in VMWare).

There are 3 parts of LSA security for a user:
. Edit RM Information [RM = Resources Manager]
. Manage Identities
. Edit Lawson Environment Information

1. Edit RM Information [RM = Resources Manager]
In LDAP:
. ADAM instance
. . cn=lwsn,dc-<your-adam-instance>
. . . O=lwsnrmdata
. . . . OU=resources <<------

This branch is the Users. One user - one RMID - per entry. Lawson considers Users to be Resources. Each entry is self-explanatory -- fill in as needed, compare to the LDAP entry. There is a one catch: Since Ldif entries only appear for filled-in items, all items have one additional setting that is not shown! That setting is the "missing" or "not filled in" setting. In some case this setting is significant. When I set up reporting on LDAP, using a VBA script, I had to specifically search for all possible settings, all possible groups, all possible roles, and report on items whether they were there or not.

Suggestion on managing this via Ldif: Be aware of the significance of "missing" entries.

2. Manage Identities
In LDAP:
. ADAM instance
. . cn=lwsn,dc-<your-adam-instance>
. . . O=lwsnSecData
. . . . OU-svcxref
. . . . . CN=<your-instance> <<--- UNIX login info
. . . . . CN=SSOP <<--- SSOP info - Active Directory

This is set up freakin' backwards! Each entry is not for the RMID, it's for the UNIX login or SSOP. So if you have more than 1 user who is using the same UNIX login or SSOP, there is only 1 entry for that UNIX login or SSOP, with multiple RMID's listed under it. For my reporting, I had to de-normalize this data by making separate entries for each and every RMID. That's the only way to link a UNIX login or an SSOP to the RMID, using a spreadsheet VLOOKUP.

(Note: It is possible to get this screwed up by having multiple UNIX logins or SSOP's pointing to the same RMID ... and that is not right, but due to the backwards nature of this kludge, it can & does occur.)

3. Edit Lawson Environment Information

[This is supposed to come entirely from LAUA. This should be relatively straight-forward. I haven't done anything with reporting here, so I have no suggestions.]

We have done this successfully, but are not using ADAM... we went the Tivoli route instead.

A script kicks off nightly - from root's cron (actually early in the morning) looking for new or re hires for the previous day (entered into Lawson) and does all of the setup required.

We are still using LAUA security, though, and I suspect that once we move to using LS, we'll have to change things a bit.

We're also creating separate sign-ons for ESS and normal Lawson App users... so if you are both, you'd use one login to get to ESS and another (manually set up) one to get to your Lawson applications.

Milo, thanks for the info. We had kind of found some of that stuff doing some testing - yes, this set up is VERY funky!

Is there any suggestion on how to get the correct CN when doing the updates for a user? Our thought was do we need to somehow query the LDAP for the user desired to get the CN for all of the parts...or do we need to store the CN with the user on some xref data somewhere?

Just wondering thoughts on this...

Surely Lawson would have thought there might need to me an external need for these functions in addition to initial load?

Getting the correct CN is easy with the RM info in that first tree. But with the Resources info, it's backwards so it's hard.

I don't think you necessarily need an external storage resource ... why not take an LDIF dump, parse & analyze it (like I do with a bit of VBA) and take your calculations from there?

Can you share how you are doing your LDIF dump? I'm not an LDIF expert, but not a novice either and I can't seem to get the resource attributes dumped (PortalAdmin, AddIns, etc....)

Are you using an ldifde command or some other tool? I see that you've referenced using VB, but it looks like to you mean on the data AFTER you've dumped it.