RE: [ActiveDir] User Account Lifecyle -- Best Practices

Tue, 31 Jan 2006 20:56:51 -0800

First, thanks for the very thoughtful responses. Al, I appreciate the “business requirements” concept. Unfortunately, around here, no one even thinks about this at all. I need to lead them in this direction. So, given that a business process needs to be developed…

 

Questions:

- Can you help me tease out the pros and cons of: disable (Jorge and Al), expire (Al), or rename (Neil)?

- What is the point of removing a disabled/expired/renamed account from Security Groups? If you need to re-enable the user, how will you know what groups to put it in? And, isn’t the account going to be deleted (and therefore removed from the groups) anyway?

- Do any of you push the archived data off to other media (like DVD or tape)?

 

Thanks again.

 

-- nme

 

From: Al Mulnick [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 31, 2006 6:23 AM
To: [email protected]
Subject: Re: [ActiveDir] User Account Lifecyle -- Best Practices

 

Noah, I think by this point you can see that answers vary.  The variables are the business requirements.

 

An organization I did similar for looked at this as account lifecycle management.  'Cradle to grave process.'

 

Similar to the other posts, I helped define a process and then semi-automate it.  The process definition is the important part.  Being able to reconstruct the user object is the second most important after that. Being able to automate it was the third priority because it was felt that fewer mistakes would be made, it would require less effort to be expended, and it would be a consistent process.  

In that environment, the process all started with an authoritative notification of expiry.  From there, the accounts were removed from groups, moved to a new OU, marked with the deletion date, disabled, etc.  Everything that was done was logged in such a way that it was easy to put this back with a minimal of effort and with audit capability in mind.  No task was done without logging because of the compliance requirements surrounding the company's business. 

 

This is a repetitive task and should be automated as much as possible. How exactly you decide to do this is more a question for your business leaders.  Automating it is something you can either do or not do, but once it's a defined process I see no reason to manually do anything in this situation. 

 

Additionally, I've always broken the whole lifecycle into several parts: 

1) provisioning (cradle) 

2) De-provisioning (grave) 

3) modifications (all that stuff in between)

 

Automating provisioning of a new account is something that should be automated.  Automating removal of accounts should also be automated in my opinion.  Whenever possible, modifications should be semi-automated so you can capture what tasks were performed with a minimal of effort on the part of the administration team.  In a perfect world, it should be so routine and easy that either the user can do it or my least trained and experienced staff member can do it without error. That just about screams automation to me. 

 

Start by defining the process requirements.  Does your company require that the account be immediately unable to be effective? Expiring the account alone has some drawbacks in terms of time.  Disabling has some other trade-offs.  But removing the user's ability to be used immediately upon notification is a security best practice. Archival depends on your company needs, but it's typically something that you want to have happen after a decent amount of time.  Why? Because users tend to leave and come back.  Similar to backups, you want to reduce the amount of time to perform a restoration of any kind.  This is no different.  Tune the process to accomdate the way your organization works and you'll save yourself a lot of time.

 

My 0.04 (USD) worth anyway,

 

Al 

 

On 1/31/06, [EMAIL PROTECTED] <[EMAIL PROTECTED] > wrote:

Just my 2 penneth, but I have found that a rename of the user rather than a user move can work better.

 

If the user is moved and then needs to be moved back to the original location, you may encounter issues without a record of their original OU.

 

Consider adding a suffix to the user name - e.g. bloggsj_left_31012006 (I've used ddmmyyyy but of course mmddyyyy is acceptable too :)

 

neil

 

From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Almeida Pinto, Jorge de
Sent: 31 January 2006 09:37
To: [email protected]
Subject: RE: [ActiveDir] User Account Lifecyle -- Best Practices

 

Hi,

 

I wrote the following a while ago... See if you can use the procedure

 

What to do with user accounts that are or not mailbox enabled when the corresponding user(s) leave(s) the company. For that and without buying a full blown solution you can create tooling in a simple way if the following process is sufficient for you.

IT IS A 5 STEP PROCESS:
(1) Be sure to receive some notification a user has left the company
(2) Move its user account to a special de-provisioning OU (manually)
(3) Schedule a script to run regularly (dayly or weekly or whatever is good for you) to disable AD enabled user accounts in the de-provisioning OU and if the account is mailbox enabled to add the "Associated External Account" permission to SELF. Also generate and set a difficult password (be carefull with certificates if you use them for encryption!)
(4) Schedule a script to run regularly (dayly or weekly or whatever is good for you) to check the de-provisioning OU for disabled user accounts that have been unused for a certain (inactive) period (e.g. 90 days). In a W2K3 domain with Domain Functional Level 'Windows Server 2003' you can use the 'lastLogonTimestamp' attribute that determines the last time a user logged on. In a W2K domain or W2K3 domain with Domain Functional Level 'Windows Server 2000 native' or lower you can use the 'lastLogon' attribute which is less accurate, but that will do.
If user accounts are found that meet the prerequisites (disabled and exceed a certain inactive period):
* Create a directory for the user in some "Archive Location" (the archive location is a location where the user's stuff will be copied to, backup for a certain time and after some other period the user's stuff is removed)
* Extract all populated attibutes of the user account to the user's archive location (using LDIFDE)
* Check if a home directory exists (read attribute and check location) and MOVE it to the user's archive location
* Check if a profile directory exists (read attribute and check location) and MOVE it to the user's archive location
* Check if a TS home directory exists (read attribute and check location) and MOVE it to the user's archive location
* Check if a TS profile directory exists (read attribute and check location) and MOVE it to the user's archive location
* Exmerge the mailbox into a PST in the user's archive location (be carefull with large PST sizes!!! e.g. > 2GB)( http://support.microsoft.com/default.aspx?scid=kb;en-us;830336)(http://support.microsoft.com/default.aspx?scid=kb;en-us;823176)
(5) Schedule a script to run regularly (dayly or weekly or whatever is good for you) to check the all user's archive locations to see which exceed the archiving period for backup ( e.g. 60 days). For this compare the folder creation date with the current date. If a user archive location is found and it is older than the current date minus the minimum required archiving period for backup, delete the folder


 

cheers,

Jorge

 

From: [EMAIL PROTECTED] on behalf of Noah Eiger
Sent: Tue 2006-01-31 04:00
To: [email protected]
Subject: [ActiveDir] User Account Lifecyle -- Best Practices

 

Hi –

 

Can someone recommend or point me to best practices for user account management? I guess that in large organizations this is either automated or some junior tech jockey is assigned to handle this full time. In smaller organizations, what is on the checklist when a user leaves? Do you disable or expire the account? Does this happen the day the user leaves? How long before archiving home directory and email? When are accounts finally deleted?

 

Any pointers welcome.

 

Thanks.

 

-- nme

 

--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.14.24/244 - Release Date: 1/30/2006

PLEASE READ: The information contained in this email is confidential and

intended for the named recipient(s) only. If you are not an intended

recipient of this email please notify the sender immediately and delete your

copy from your system. You must not copy, distribute or take any further

action in reliance on it. Email is not a secure method of communication and

Nomura International plc ('NIplc') will not, to the extent permitted by law,

accept responsibility or liability for (a) the accuracy or completeness of,

or (b) the presence of any virus, worm or similar malicious or disabling

code in, this message or any attachment(s) to it. If verification of this

email is sought then please request a hard copy. Unless otherwise stated

this email: (1) is not, and should not be treated or relied upon as,

investment research; (2) contains views or opinions that are solely those of

the author and do not necessarily represent those of NIplc; (3) is intended

for informational purposes only and is not a recommendation, solicitation or

offer to buy or sell securities or related financial instruments. NIplc

does not provide investment services to private customers. Authorised and

regulated by the Financial Services Authority. Registered in England

no. 1550505 VAT No. 447 2492 35. Registered Office: 1 St Martin's-le-Grand,

London, EC1A 4NP. A member of the Nomura group of companies.

 

--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.14.25/246 - Release Date: 1/30/2006


--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.14.25/246 - Release Date: 1/30/2006

Reply via email to