Well if you want to build an entire lifecycle management
mechanism, extending your schema is probably one of the more flexible ways of
going because you can work out your strategy and maintain the info you want,
like when it was last approved as ok, when it needs to be approved again,
alternate approvers if the managedby isn't accurate, special handling or
instructions, etc. It depends on internal process. You can also pack all of that
info into a single attribute that already exists but depending on your use of
the directory and what products you have out there it may be fun to find one
that makes sense. As Jef mentioned though, just for ID type, I do recommend a
simple thing like employeeType to be used and define your meanings for the
values. At the very least setting employeeType gives you something to filter on
when cleaning up so you don't have to look at everything as one type and work it
all out each time.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rimmerman, Russ
Sent: Friday, April 28, 2006 5:05 PM
To: [email protected]
Subject: RE: [ActiveDir] Cleanup of AD accounts
Is there an attribute that's generally safe to use, or
are you suggesting we request an OID from Microsoft and make our own
boolean "ourcompanyServiceAccount" attribute?
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe
Sent: Friday, April 28, 2006 2:44 PM
To: [email protected]
Subject: RE: [ActiveDir] Cleanup of AD accounts
And I look and see that I received it. Glad you like oldcmp
btw... :)
First
off, you don't need the -f option with the user filter in there, the -users will
take care of that for you.
Second
off, no there is no mechanism in it right now to allow you to exclude accounts
based on a text file.
I
would highly recommend to you as I have recommended to countless others that if
you have accounts that aren't updating their passwords because they are set to
non-expiring or you don't have a password policy and they are supposed to not be
getting updated that you set up an attribute in AD to note that they are special
like that. Most larger companies requires some sort of registration process for
non-expiring Service IDs so that people can chase them down later and then you
just stamp some attribute (existing or something you add) to the directory to
flag them as special. Then you just use the -af switch to add the piece of the
filter that lets you ignore them, alternatively put them in a special OU and
either avoid that OU with the base you set in oldcmp or use the exclude DN
switch which should be -excldn if I wasn't completely intoxicated when
I coded it. :)
You
are welcome a bunch.
joe
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rimmerman, Russ
Sent: Friday, April 28, 2006 11:34 AM
To: [email protected]
Subject: [ActiveDir] Cleanup of AD accounts
Joe - I sent you an
e-mail, I figured maybe going to this list might get more input on this question
as well:
If I wanted to run an oldcmp -report 120 -users -sort cn -f
"(&(objectcategory=person)(objectclass=user))" -format csv -delim
,
and then send it out
to our remote administrators to 'remove any accounts you don't want
disabled'
and then take the
final list and disable all remaining accounts
that they didn't flag as still being used,
how would I accomplish that?
Is there a way
to have oldcmp use a modified file as an import file for the accounts to
disable? Our problem is we don't want to disable any service accounts that
are actively being used, but we have a LOT of
cleanup to do. How does everyone else handle
this?
Thanks a
bunch,
Russ
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This e-mail is confidential, may contain proprietary information of the Cooper Cameron Corporation and its operating Divisions and may be confidential or privileged. This e-mail should be read, copied, disseminated and/or used only by the addressee. If you have received this message in error please delete it, together with any attachments, from your system. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This e-mail is confidential, may contain proprietary information of the Cooper Cameron Corporation and its operating Divisions and may be confidential or privileged. This e-mail should be read, copied, disseminated and/or used only by the addressee. If you have received this message in error please delete it, together with any attachments, from your system. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
