LSF9 - deactivate user accounts?

Anya, There isn't an easy way to do this, as there is no longer an attribute that properly handles this, as the Inactive flag did in 8.0.3. With that said, you could do anyone of the following: 1) Remove the SSOP identity on the user record 2) Set them to a non-existent portalrole file *** They would get an error on login, if I recall correctly 3) Set them to a severly restricted portalrole file (ie: noaccess.xml) *** They could still login, BUT would be able to get to anything 4) Set them to a non-existent OS Identity/LAUA Security Class (they still could log in though) 5) Disable them via custom setup for LDAPBind (tricky, but appropriate for some clients) ...Now as far as out-and-out deletes, Lawson has the ability to do them en-masse, but you would have to code up something in Java to access the internal APIs ...if you want more detailed advice, feel free to call me. Kwane 954.547.7210

Thanks, Kwane, that was quick! I like the 2nd option, we can do it through the .xml file. We do need to remove SSOP identities also, do you know of a way we could automate this?
Also, if you could elaborate a bit on the 4th option? We are very new at this. :o)

Hey All,

Did you arrive at a final solution. I like the idea of coding something in Java for the internal API's did you give that route a shot at all? I'll let you know if I have any luck.

My 2 cents here: When you inactivate or remove user accounts, make sure any existing reports and jobs are transferred to someone else if necessary. For example, if you're deleting a finance user or payroll user and they run important reports then just make sure they get transferred to someone else. I've seen mistakes where the accounts get deleted along with all of their jobs and reports (especially if you're using deljobhist). Oh, and I've also seen where a customer has custom account removal programs that remove ANY files on the app server where the user owns a file(s)  ... can be very dangerous. -Roger

Roger - as far as mass deletion you could simulate the security administrator calls which basically go against LSGate servlet using http calls. There are 3 calls that you can trace using external tools and program in whatever langage you wish. This will allow you to remove the RM Profile/Identities/GEN Record and delete or distribute jobs/reports to a specified user. The only thing you need to be aware if you go that path is that there is a env. patch PT-178504 that you ll have to install.
- christos

Roger,
If there's anyone you should DEFINITELY Listen to, it is Christos. I hinted at this in an earlier post, but didn't want to elaborate, due to it being alot of work. I think that's why he didn't go into detail either.

Christos is one of THE ORIGINAL authorities on the internals of this thing. I'll allow him to explain if he chooses.
If he says it concerning Lawson Security internals, consider it gospel...PERIOD.

With that said, I would expand his statement to the following: There are 5 calls total you need to emulate, in order to make the utility bullet-proof. The 3 he refers to are the core of the tasks, one of the other needs to be looped in there as well.

There are nearly 200 calls that do all kinds of things very useful. The key is knowing how to find those calls.

Christos, call me when you get the chance to catch up.

Kwane
954.547.7210

That makes sense. I'll check out that patch, and then see where we can go with this approach.

Thanks :-)

In relations to satisfying auditors, what would be the best way to easily deactivate the users w/o having to write a program. Wouldn't the removal of the sso identity be enough?

We are on lsf9, but maintain LAUA security at this time.

Is an LDAP Bind enabled in LSF9 to your AD? If so, then the lock of the user accounts falls to the Windows admins vs the Lawson Admins. A portal cannot login to Lawson once their account is locked on AD, due to the bind. If your accounts on the os are local, then you would need to have the Windows admin disable the accounts on the os side, if you have them local without login, this would satisfy also SOX Audits. I have worked on this with SOX Auditors directly and it satisfies their concerns. Hopefully the bind works within your LSF9 instance.

We are bound and I love the idea of leaving this in the hands of the network folks. I'll be sure to check with them to ensure that they never delete and/or reuse a network logon ID. Thanks for the input!

Posted By Kwane McNeal on 11/12/2008 01:15 PM  1) Remove the SSOP identity on the user record Kwane 954.547.7210

How would you remove the SSOP identity for an individual user?  We are searching manuals and haven't found anything yet?  Thanks!

-Shari

 

Shari: Pull up the user in LSA, right click | Manage Identities | Highlight SSOP | File | Delete

Thanks...was kind of looking for an automated way to do this.  Thanks anyway!

 

-Shari

From Lawson Security Administrator, User Management, User Maintenance. Search for the user, then right-click in the query results and select "Manage Identities". Highlight SSOP in the list of services, then select 'Edit|Delete' in the menu bar.

Thanks, John - I really need an automated way to do this.  We use loadusers to provision our users, would like to do something similar to remove the identity.

 

-Shari

If you are on 9007 or higher, the loadusers utility has a -u switch for "unloading" users. The switch will not show up in any of the help doco.

You could also go directly after the LDAP but, this would involve a little script writing

Is anyone familiar with how to utilize this -u switch with the loadusers utility? We're on environment 9.0.0.7, using LSF9 security on Windows2003 (and Active Directory, but we're not yet lDAP bound). We currently use the loadusers utility to add out users and knowing how to utilize this switch to "unload" them would be very useful. TIA!!

I've used this to remove users. This is what I know: (be sure to test this out)... loadusers -f yourfilename.xml -p PRODUCTLINE -u (it may require you to put the domain): loadusers -f yourfilename.xml -p PRODUCTLINE -d UMC -u I've found that the userid used is not the one on the rm record...but the identity record, which equates to their logon...for us it is usually the same, but not always... the file as an example could look like this: (the blank tags may not be needed, I left them in my file).

Beverly - does that remove everything? The RMID as well as all of the identities, and the LDAP entries too?

this should remove it from ldap and the rm tool...all pieces and should emmulate what would happen if you used the rm tool to REMOVE a person. Test it out with one person first. I think it was in the release notes (using loadusers for deleting).

Thanks. I had found the documentation, but it really was vague as to what exactly it was removing. I'll be testing this in the next few days. One thing... --->I've found that the userid used is not the one on the rm record...but the identity record Are you talking about the Environment/Service Indentity?? We have multiple env-identities for many users. How would this mass-delete work if it's starting with the identity and not the RMID itself?? Have you tried it in the cases with mulitple environment/service id's??

Well, never mind. I've tested it and it does in fact remove everthing.