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:* ActiveDir@mail.activedir.org
*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:* ActiveDir@mail.activedir.org
<mailto:ActiveDir@mail.activedir.org>
*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:* ActiveDir@mail.activedir.org
<mailto:ActiveDir@mail.activedir.org>
*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:* ActiveDir@mail.activedir.org
<mailto:ActiveDir@mail.activedir.org>
*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
<http://support.microsoft.com/default.aspx?scid=kb;en-us;830336%29%28http://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-4ae7-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-47DC-96DA-1C12D67327D5&displaylang=en
<http://www.microsoft.com/downloads/details.aspx?FamilyID=429163EC-DCDF-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:* ActiveDir@mail.activedir.org
<mailto:ActiveDir@mail.activedir.org>
*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.
