O dear - that's embarrassing :(
you are correct.
I might stop blushing by the weekend!
------------------------------------------------------------------------
*From:* [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] *On Behalf Of *Creamer, Mark
*Sent:* 02 February 2006 15:47
*To:* ActiveDir@mail.activedir.org
*Subject:* RE: [ActiveDir] User Account Lifecyle -- Best Practices
Actually I believe PhD is Doctor of Philosophy, not Psychology.
All in all, interesting article. Here in beaurocracy-central, we have
what many used to consider a liberal lockout policy, and then in an
interesting twist of post-Sarbanes-Oxley irony, we have a guy doing a
Six Sigma project to figure out how to reduce calls to the help desk,
which as it turns out, the majority of which are due to account
lockouts <sigh>
I wish I had 1 Millionth of the money companies are wasting thanks to
our government’s post-Enron/MCI/et al panic. But that’s another story.
*/<mc>/* , not PhD
------------------------------------------------------------------------
*From:* [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] *On Behalf Of
[EMAIL PROTECTED]
*Sent:* Thursday, February 02, 2006 10:01 AM
*To:* ActiveDir@mail.activedir.org
*Subject:* RE: [ActiveDir] User Account Lifecyle -- Best Practices
//Dr J (PhD - means what exactly?)//
- Doctor of Psychology. In short, the guy took a 3 year degree and
then took a 3 year post grad PhD course (doesn't matter what the
subject matter was). He is therefore known as *Dr* Jesper J.
What is the equiv over your side of the pond?
neil
------------------------------------------------------------------------
*From:* [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] *On Behalf Of *Al Mulnick
*Sent:* 02 February 2006 14:02
*To:* ActiveDir@mail.activedir.org
*Subject:* Re: [ActiveDir] User Account Lifecyle -- Best Practices
This is fun :)
Dr J (PhD - means what exactly?)
I think you're referring to this section of the paper in the first link
*Why You Should Not Use Account Lockout*
Even though the guide recommends configuring account lockout at 50
tries, I urge you not to configure account lockout. First, as the
initial article of this series described, the chances that an attacker
will guess a reasonable password are so remote as to not justify this
option. Second, an attacker is highly likely to take your account
lockout setting and convert it to a denial-of-service attack by
locking out every account on the system. Third, most vulnerability
assessment tools will lock out all the accounts on your domain. In the
end, whether you use account lockout is a matter of your security
policy, and debate whether it provides value. Keep in mind, however,
that account lockout problems represent some of the most frequent
technical support issues with Microsoft support services, and
resetting an account costs an average of $70 per incident. If your
security policy is so stringent that you believe these numbers are
acceptable, and your policy cannot enforce reasonable passwords, you
might still choose to configure account lockout. If not, do your Help
Desk and budget a favor, and avoid it.
I see the point. I disagree with the assertion that seems to have been
throttled back for public consumption. I also would say that if your
vulnerability assessment tool locks out your accounts after 50 tries,
you're using the wrong vulnerability tool. Microsoft should consider
using automated reset tools if it costs them that much <G>
No, in the end I'm a believer that if your user can't get the password
right after x number of tries (in this case, 50 is the recommended)
then they SHOULD call the helpdesk because <insert deity> knows that
they need it at this point. No question in my mind. And that type of
support incident is exactly what a help desk is for: silly user
tricks. Does that apply to SBS? In my opinion it should. If you can't
remember your password after 10 tries, odds are you aren't going to.
Write it down and paste it under your keyboard if it's such a problem.[1]
I don't think I recognize Steve in that last link. His hair looks
blonde in that photo. ??
In the end Susan, I get what they're trying to say. I know they're
trying to make a case for not using account lockout and are using the
cost as a justifying factor. They're also pushing for the use of long
pass phrases vs. passwords. I've even heard some comments to the
effect of using passphrases that insanely long and not ever requiring
the user to change it. Additionally, there was a report not long ago
by some brain-trust reporting org that predicts the usage of passwords
will be insufficient by 2007 (can't find the link at the moment, but
I'll have a look next opportunity if you like) because password
crackers will be too good. Does this point to an idea that we should
do away with passwords, account lockout, and password complexity? I've
heard California is going to fall in the ocean due to some massive
earthquake. I haven't decided to buy beach front property in Nevada
yet nor do I think that doing away with account lockout is the answer
to the problem. Neither are super-long passphrase requirements nor
smart card logons, etc. These are all parts of a solution, but not the
end because this is not a one-size fits all solution.
FWIW, it is not the first time I've disagreed with Microsoft's
assertion on security matters. Usually not because they're technically
wrong, but because they don't have enough perspective to make it work
in more than one scenario. I recall many long conversations regarding
ISA and whether DMZ topology was valid anymore (or less). I think we
still have different perspectives. That's how they work though:
they'll continue to refine the ideas until it is the best idea out
there. I respect and admire that very much. I also strive to get to
that level of refinement.
[1] let's face it, you may want to find another line of work anyway. I
in no way endorse that idea, but rather just want to use it to
illustrate a point. Hopefully nobody takes that seriously but if you
do, do so at your own risk!
"Security - Does one size fit all?" -ajm
On 2/1/06, *Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]*
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
Dr. Jesper Johansson
Steve Riley
Up there with the Gibson titled "rogue developers" you know.....
"Protecting your Windows Network"
http://www.microsoft.com/technet/community/columns/secmgmt/sm1204.mspx
Specifically
http://www.microsoft.com/technet/community/columns/secmgmt/sm1204.mspx#ECAA
http://www.protectyourwindowsnetwork.com/listening_room.htm
Al Mulnick wrote:
Dr J? Irving?
Riley = you mean Steve of the Northwest Riley Clan? Or somebody else?
I can say there are others that disagree with the idea of not having
account lockout settings (assuming that's what was exactly said and
not knowing the context) as well, because that option exists in the
products. Somebody somewhere thinks it's of value. I happen to be one
that finds value in being able to lockout an account after a certain
number of bad attempts. I'm also a person that believes that the
account should become usable again after a predefined amount of time
without human intervention. Why? Because people make mistakes. That
shouldn't cost valuable helpdesk time. Besides, the idea is to
prevent automated attacks, not access to the system for normal user
usage patterns.
I have to say Susan, it's an interesting perspective that you bring.
I believe that something that acts as a guideline vs. a checklist has
value however. I don't see this as something that would be a
checklist. I'm not a beancounter (although I've played one on the
internet a few times) but I loathe doing things because somebody else
thought it was a good idea. I need more information than that. A
guide is sometimes helpful in doing that because if nothing else it
helps to focus my thoughts. I use some of the books that are out
there that way as well. Some of the books are better suited to help me
get that glass off the top shelf though.
Interesting.
On 2/1/06, *Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]*
< [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
<mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> wrote:
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]
<mailto:[EMAIL PROTECTED]>
<mailto:[EMAIL PROTECTED]
<mailto:[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]>
<mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>
> [mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
<mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>] *On Behalf Of *Al Mulnick
> *Sent:* Wednesday, February 01, 2006 11:00 AM
> *To:* ActiveDir@mail.activedir.org
<mailto:ActiveDir@mail.activedir.org>
<mailto: ActiveDir@mail.activedir.org
<mailto: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]>
<mailto: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
<mailto: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>>* <
> [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
<mailto: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
<mailto: [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]>>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
<mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>> [mailto:
> [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
<mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
<mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>>] *On Behalf Of
> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
<mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
<mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
<mailto: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>>
> *Sent:* Wednesday, February 01, 2006 3:37 AM
> *To:* ActiveDir@mail.activedir.org
<mailto:ActiveDir@mail.activedir.org>
<mailto: ActiveDir@mail.activedir.org
<mailto:ActiveDir@mail.activedir.org>>
> <mailto:ActiveDir@mail.activedir.org
<mailto:ActiveDir@mail.activedir.org>
<mailto: 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]>
<mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
> <mailto: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]><mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>>]
> *Sent:* Tuesday, January 31, 2006 6:23 AM
> *To:* ActiveDir@mail.activedir.org
<mailto:ActiveDir@mail.activedir.org>
<mailto:ActiveDir@mail.activedir.org
<mailto:ActiveDir@mail.activedir.org>>
> <mailto: ActiveDir@mail.activedir.org
<mailto:ActiveDir@mail.activedir.org>
<mailto: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]>
<mailto: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
> <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
<mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>>* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
<mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
> <mailto: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
<mailto:[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]>>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
<mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>> [mailto:
> [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
<mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>
> <mailto:[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>
<mailto:ActiveDir@mail.activedir.org
<mailto:ActiveDir@mail.activedir.org>>
> <mailto:ActiveDir@mail.activedir.org
<mailto:ActiveDir@mail.activedir.org>
<mailto: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>
<http://support.microsoft.com/default.aspx?scid=kb;en-us;830336%29%28http://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>>
> <
http://support.microsoft.com/default.aspx?scid=kb;en-us;830336%29%28http://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>
<
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>>
>
<
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>
<
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>
<
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>>
>
<
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>
<
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]>
<mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
<mailto:[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>
<mailto:ActiveDir@mail.activedir.org
<mailto:ActiveDir@mail.activedir.org>>
> <mailto: ActiveDir@mail.activedir.org
<mailto:ActiveDir@mail.activedir.org>
<mailto: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.
>
>
--
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
< http://www.activedir.org/ListFAQ.aspx>
List archive:
http://www.mail-archive.com/activedir%40mail.activedir.org/
--
Letting your vendors set your risk analysis these days?
http://www.threatcode.com
List info : http://www.activedir.org/List.aspx
<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/
<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.
This e-mail transmission contains information that is intended to be
confidential and privileged. If you receive this e-mail and you are
not a named addressee you are hereby notified that you are not
authorized to read, print, retain, copy or disseminate this
communication without the consent of the sender and that doing so is
prohibited and may be unlawful. Please reply to the message
immediately by informing the sender that the message was misdirected.
After replying, please delete and otherwise erase it and any
attachments from your computer system. Your assistance in correcting
this error is appreciated.
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.
