I agree with 99% of the below, but would add that cases such as Enron highlight the need for *some* best practices and that anything is better than nothing.
SOX and the like insist that orgs adopt some kind of methodology and framework which shows they performed due diligence before making changes. Certainly, it should not be *just* a checklist - Enron and SOX have however forced us all to look at what we do and how we do it. neil PS Maybe Enron was an unfortunate example to originally cite :) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] Sent: 01 February 2006 21:21 To: [email protected] Subject: Re: [ActiveDir] User Account Lifecyle -- Best Practices The problem with some of this is that books become stale...and what is "best practices" today is not tomorrow with regulation and law changes. Then my pet peeve is that I don't believe that you can have one best practice. And as a beancounter who's industry and profession wrote the book on "follow the checklist as that's the way to do things" do I need to remind folks of the Enron case going on? This little SBSer thinks that best practices should be a discussion item...not a checklist to follow. And it's my opinion that too many times we check the box and don't think. But then again I can say that because small firms have less politics than big ones. Example of a recommendation that I disagree with ... Dr. J and Riley say all the time that they don't recomment account lockout settings as it's a $75 help desk call. In SBSland.. it's never been an issue and puts a smidge more protection given that we tend have less layers. Some of these decision tree kind of stuff is also discussed in the MS pdf "Threats and Countermeasures". But even then you have to decide what the risk is for your firm. In my own firm, short term employees, I blew them off ages ago, long term employees I kept the accounts around, employees that had an HR problem... that mailbox is still sitting on my server (yeah I should pst park it but it's easier just to disable it and leave it there). To me these policies need to be compared with what HR issues there are with this terminated employee, in fact we had discussion in a SANS course that you may even want to image his/her workstation and leave it intact for forensic purposes. [EMAIL PROTECTED] wrote: > Well they sure don't teach this in college courses! A list of > questions to help define the scope of account management would be very > useful. You could then answer the questions with the pros and cons of > the various solutions. For example, address the Account Lockout > policies and then answer with the options to lock out and never > unlock, lock out and unlock after a specific time period, or not lock > out at all. All three are options but it would be great to have a book > that puts them all in one place with the pros/cons listed so people > can make an informed decision and pick the option that is best for > their situation. Tis better to give options and let someone make their > own decisions then to make the decision for them and get blamed for it > later down the road. > ---------------------------------------------------------------------- > -- > *From:* [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] *On Behalf Of *Al Mulnick > *Sent:* Wednesday, February 01, 2006 11:00 AM > *To:* [email protected] > *Subject:* Re: [ActiveDir] User Account Lifecyle -- Best Practices > > There are several schools of thought on this concept. There are > websites regarding identity management but I'm not sure it's what > you're looking for. The idea of identity management is something that > is inherent in any networked or even standalone system that has a > computer. Your ATM, Television contract, Phone Service, and other > identities are all included in the same concept. I have not seen > anything specifically around this area of the concept, but I think > that's more or less because it's so inherent in the ownership of the > system that most people haven't really stopped to consider the pieces > that make up the whole. > Do you think an article is warranted in this case? Or should it be > book length? What would you want to see different from what the myriad > of vendors put out there (vendors such as Microsoft, IBM, Cisco, > Abridean, etc.)? > I'm curious what the thinking is here and how much of a need there > really is for this type of discussion. I know that Tony has been after > folks to blog some items and I know that Jorge did blog some of this. > But if you think more is needed beyond what Jorge did, I'd be > interested to know. I'd also bet that Jorge might be writing as we > speak :) > > On 2/1/06, [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>* < > [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Is there possibly a book or website that might contain more > in-depth documentation on this subject? > > ------------------------------------------------------------------------ > *From:* [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> [mailto: > [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>] *On Behalf Of > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > *Sent:* Wednesday, February 01, 2006 3:37 AM > *To:* [email protected] > <mailto:[email protected]> > *Subject:* RE: [ActiveDir] User Account Lifecyle -- Best Practices > > Comments inline. > > 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)? > [Neil Ruston] I prefer the rename rather than move etc since (as > you state below) if the user needs to be 'reanimated' it may prove > difficult to configure him/her back to their original state. I > have seen many a user 'leave' only to re-join the firm within > weeks or months, or to not actually leave at all. Naturally, you > need to take your lead from HR, but they can sometimes 'jump the > gun' :) I therefore prefer to rename and disable. > > - 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? > [Neil Ruston] See above comment. > > - Do any of you push the archived data off to other media (like > DVD or tape)? > [Neil Ruston] User data should be backed up regularly anyway, so I > have not encountered a need to perform additional archives. > > Thanks again. > > -- nme > > > ---------------------------------------------------------------------- > -- > > *From:* Al Mulnick [mailto: [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>] > *Sent:* Tuesday, January 31, 2006 6:23 AM > *To:* [email protected] > <mailto:[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] > <mailto:[EMAIL PROTECTED]>* <[EMAIL PROTECTED] > <mailto:[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]> [mailto: > [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>] *On Behalf Of > *Almeida Pinto, Jorge de > *Sent:* 31 January 2006 09:37 > *To:* [email protected] > <mailto:[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://s upport.microsoft.com/default.aspx?scid=kb;en-us;823176 > <http://support.microsoft.com/default.aspx?scid=kb;en-us;830336%29%28htt p://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 > > TOOLS USED: > * ADModcmd.exe and others from (ADModify.NET) ( > http://www.gotdotnet.com/workspaces/workspace.aspx?id=f5cbbfa9-e46b-4a7a -8ed8-3e44523f32e2) > * Robocopy.exe (tested with: v5.1.1.1010) (W2K3 Resource Kit) ( > http://www.microsoft.com/downloads/details.aspx?FamilyID=9d467a69-57ff-4 ae7-96ee-b18c4790cffd&displaylang=en > <http://www.microsoft.com/downloads/details.aspx?FamilyID=9d467a69-57ff- 4ae7-96ee-b18c4790cffd&displaylang=en>) > * ExMerge.exe (tested with: v6.5.7529.0) ( > http://www.microsoft.com/downloads/details.aspx?FamilyID=429163EC-DCDF-4 7DC-96DA-1C12D67327D5&displaylang=en > > <http://www.microsoft.com/downloads/details.aspx?FamilyID=429163EC-DCD > F-47DC-96DA-1C12D67327D5&displaylang=en>) > > > cheers, > > Jorge > > > ---------------------------------------------------------------------- > -- > > *From:* [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> on behalf of Noah Eiger > *Sent:* Tue 2006-01-31 04:00 > *To:* [email protected] > <mailto:[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 > > 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. > > -- Letting your vendors set your risk analysis these days? http://www.threatcode.com List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ 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. List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
