PrevPrev Go to previous topic
NextNext Go to next topic
Last Post 08/03/2010 2:08 PM by  beverly godwin
LSF9 - deactivate user accounts?
 25 Replies
Sort:
You are not authorized to post a reply.
Author Messages
Anya
Private
Private
New Member
(5 points)
New Member
Posts:3


Send Message:

--
11/12/2008 1:08 PM

    We are migrating to LSF9 and using ADAM ldap. I know there is no Lawson command yet to  mass delete user accounts from ADAM. But I was wondering if there is a simple way to de-activate the accounts? Thanks!

    Kwane McNeal
    Private
    Private
    Veteran Member
    (1197 points)
    Veteran Member
    Posts:399


    Send Message:

    --
    11/12/2008 1:15 PM
    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

    Anya
    Private
    Private
    New Member
    (5 points)
    New Member
    Posts:3


    Send Message:

    --
    11/12/2008 2:00 PM
    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)
    cdodrzywolski
    Basic Member
    (47 points)
    Basic Member
    Posts:21


    Send Message:

    --
    11/24/2008 2:05 PM
    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.
    Roger French
    Private
    Private
    Veteran Member
    (1266 points)
    Veteran Member
    Posts:522


    Send Message:

    --
    11/25/2008 8:17 AM

    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

    Christos Toyas
    Private
    Private
    New Member
    (3 points)
    New Member
    Posts:1


    Send Message:

    --
    12/01/2008 9:30 AM
    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
    Kwane McNeal
    Private
    Private
    Veteran Member
    (1197 points)
    Veteran Member
    Posts:399


    Send Message:

    --
    12/01/2008 10:23 AM
    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
    cdodrzywolski
    Basic Member
    (47 points)
    Basic Member
    Posts:21


    Send Message:

    --
    12/02/2008 9:22 AM
    That makes sense. I'll check out that patch, and then see where we can go with this approach.

    Thanks :-)
    beverly godwin
    Veteran Member
    (305 points)
    Veteran Member
    Posts:143


    Send Message:

    --
    10/02/2009 2:56 PM

    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?

    beverly godwin
    Veteran Member
    (305 points)
    Veteran Member
    Posts:143


    Send Message:

    --
    10/02/2009 2:57 PM
    We are on lsf9, but maintain LAUA security at this time.
    Bart Conger
    Private
    Private
    Advanced Member
    (54 points)
    Advanced Member
    Posts:18


    Send Message:

    --
    10/02/2009 3:14 PM
    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.
    beverly godwin
    Veteran Member
    (305 points)
    Veteran Member
    Posts:143


    Send Message:

    --
    10/02/2009 4:19 PM
    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!
    Shari
    Private
    Private
    Veteran Member
    (194 points)
    Veteran Member
    Posts:78


    Send Message:

    --
    02/22/2010 9:12 AM
    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



     

    Greg Moeller
    Private
    Private
    Veteran Member
    (3873 points)
    Veteran Member
    Posts:1377


    Send Message:

    --
    02/22/2010 9:37 AM
    Shari:

    Pull up the user in LSA, right click | Manage Identities | Highlight SSOP | File | Delete
    Shari
    Private
    Private
    Veteran Member
    (194 points)
    Veteran Member
    Posts:78


    Send Message:

    --
    02/22/2010 9:38 AM

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

     

    -Shari

    John Henley
    Private
    Private
    Senior Member
    (9563 points)
    Senior Member
    Posts:3205


    Send Message:

    --
    02/22/2010 9:55 AM
    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 for using the LawsonGuru.com forums!
    John
    Shari
    Private
    Private
    Veteran Member
    (194 points)
    Veteran Member
    Posts:78


    Send Message:

    --
    02/22/2010 10:37 AM

    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

    MattM
    Private
    Private
    Veteran Member
    (214 points)
    Veteran Member
    Posts:82


    Send Message:

    --
    02/22/2010 10:44 AM
    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.
    MattM
    Private
    Private
    Veteran Member
    (214 points)
    Veteran Member
    Posts:82


    Send Message:

    --
    02/22/2010 10:45 AM
    You could also go directly after the LDAP but, this would involve a little script writing
    TBonney
    Private
    Private
    Veteran Member
    (570 points)
    Veteran Member
    Posts:240


    Send Message:

    --
    04/23/2010 7:13 AM
    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!!
    beverly godwin
    Veteran Member
    (305 points)
    Veteran Member
    Posts:143


    Send Message:

    --
    04/27/2010 4:48 PM
    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).

    <?xml version="1.0" encoding="ISO-8859-1" ?>
    <XML>
    <ROLEDATA>
    </ROLEDATA>
    <GROUPDATA>
    </GROUPDATA>
    <USERDATA>
    <USER ID = "chabib"/>
    <USER ID = "phaeberle"/>
    <USER ID = "bhagan"/>
    <USER ID = "SharonP"/>
    </USERDATA>
    <IDENTITIES>
    </IDENTITIES>
    </XML>
    CindyW
    Private
    Private
    Veteran Member
    (409 points)
    Veteran Member
    Posts:159


    Send Message:

    --
    05/04/2010 10:59 AM
    Beverly - does that remove everything? The RMID as well as all of the identities, and the LDAP entries too?
    beverly godwin
    Veteran Member
    (305 points)
    Veteran Member
    Posts:143


    Send Message:

    --
    05/04/2010 1:13 PM
    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).
    CindyW
    Private
    Private
    Veteran Member
    (409 points)
    Veteran Member
    Posts:159


    Send Message:

    --
    05/06/2010 11:51 AM
    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??
    CindyW
    Private
    Private
    Veteran Member
    (409 points)
    Veteran Member
    Posts:159


    Send Message:

    --
    05/07/2010 4:17 PM
    Well, never mind. I've tested it and it does in fact remove everthing.
    beverly godwin
    Veteran Member
    (305 points)
    Veteran Member
    Posts:143


    Send Message:

    --
    08/03/2010 2:08 PM
    what info is necessary to keep regarding users that are inactivated if you are going to remove them completely?

    I'm going to create a table that houses some info for these BEFORE I hit the big bad delete button, but from an auditing standpoint, I'm not sure what is needed.
    You are not authorized to post a reply.