I think the obvious case is when a newhire account is created and the
person decides not to come to work for the company. This can happen even
if an offer letter has been accepted because we as human beings are free
to choose where we work, and even change our minds if we want to =) Not
creating the account ahead of the newhires arrival usually means at least
a work day has been wasted, and over a large organization those workdays
really add up. Of course HR practices means these should get caught and a
term notice should be processed, but in the real world HR and the hiring
manager will often forget the paperwork for fairly long periods of time.
Thanks,
Andrew Fidel
"Al Mulnick" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
12/26/2006 12:06 PM
Please respond to
ActiveDir@mail.activedir.org
To
ActiveDir@mail.activedir.org
cc
Subject
Re: [ActiveDir] Automatic user disable based on criteria
All of this assumes that the process doesn't need to be adjusted - I keep
asking myself why a process exists to allow for the creation of an account
that isn't used? That's really the root of this. After that, I have to
wonder why the various processes aren't coordinated amongst themselves
such as password resets, forgotten passwords, new account creation and
others all being aware of one another?
I think your example helps to add more information that can be used in the
decision and I agree that if you're going to base the decision on the idea
of when it was created and assume that because the password was changed
[x] amount of time after the creation of the item but NOT less than [y]
amount of time has elapsed, that it's going to be fairly reasonable to
assume that the helpdesk (or?) has intervened and you should consider
revisions to your hiring processes.
I disagree that this is enough information to make me happy though :)
I think it's a fairly good assumption, but I would much prefer to loop in
the process and thinking described in a separate thread related to
helpdesk resetting passwords (auditing, web pages, other systems, etc) and
use that information as a flag in an account removal process. It's a sure
thing that if the helpdesk hasn't reset the password since it was created
that the account wasn't used if the password also hasn't been set, right?
You have a week so it's not like this needs to be real-time. It could,
but doesn't have to be.
Happy New Year to you and the others as well*
[*] Unless this isn't the New Year for you, in which case, have a great
day!
On 12/24/06, joe <[EMAIL PROTECTED]> wrote:
I didn't read the whole chain of responses, I was just skimming and saw
these questions
"Hey joe, is there a way to see replication meta data using adfind? ;-)
If yes, I could take a peek at originating date/time for attributes."
Yes it can show you the metadata from AD (assuming K3+) and that metadata
does indeed contain originating write into.
Now that I have read it... To solve the specific issue that I read; find
enabled users who haven't changed their passwords and logged in the period
defined, you can use the metadata to help with that decision. Obviously
having DFL2 would help as well. Neither in and of themselves I think would
be authoritative on their own except in specific cases.
The problem with DFL2 and lastLogonTimeStamp is that not everything sets
that value. Try a simple LDAP bind sometime, it doesn't update lastLogon
so it in turn doesn't update lastLogonTimeStamp. It will, however, update
it if a bad auth attempt occurred prior. I never bugged that as I assume
it is by design as it is very specific and it helps cut the overhead of
the auth attempts which the simple bind is supposed to be helping with.
That way apps that do a ton of simple binds don't cause a ton of writes to
a DC.
So how would this be done? Well obviously you can't query the metadata, it
is constructed. So you need a query to give you an initial roundabout set
to work with that you can test further. I would do something like
(&(samaccounttype=805306368)(pwdlastset=0)(whencreated<=7 days).
(&(samaccounttype=805306368)(pwdlastset=0)(whencreated>=[date 7 days
ago])(!(useraccountcontrol:AND:2))
Obviously that last field would need to be generated at the time of the
query being run. So now you have a list of possibles... You could give up
here and reasonably assume that everything is fine and take on the
resulting help desk calls. I wouldn't have much if any issue with this
method unless it had already been proven there was too much collateral
damage. I would have to decide whether I wanted to be more concerned about
the method or the fact that new people need to be reset again so soon
which likely indicates a process issue or overly agressive password policy
or underly agressive hiring policy.
So you decide you need to be more fine tuned... So you look at metadata.
Right off if the unicodePwd version is 1 then the password has never been
changed and that is as authoritative as it is going to get. You definitely
know this person has NEVER changed that password. However, the obverse is
not true, you cannot assume that if the version is higher than 1 that the
password HAS been changed. The password versioning can vary based on the
creation method. Here is the metadata from two accounts created in three
different ways:
[Sun 12/24/2006 11:42:20.45]
G:\>repadmin /showmeta CN=al-testuser0,CN=Users,DC=test,DC=loc r2dc1
31 entries.
Loc.USN Originating DC Org.USN Org.Time/Date
Ver Attribute
======= =============== ========= =============
=== =========
441322 Default-First-Site-Name\R2DC2 406847 2006-12-24
10:53:00 1 objectClass
441322 Default-First-Site-Name\R2DC1 441322 2006-12-24
10:53:01 1 cn
441322 Default-First-Site-Name\R2DC2 406848 2006-12-24
10:53:00 1 description
441322 Default-First-Site-Name\R2DC2 406847 2006-12-24
10:53:00 1 instanceType
441322 Default-First-Site-Name\R2DC2 406847 2006-12-24
10:53:00 1 whenCreated
441322 Default-First-Site-Name\R2DC2 406849 2006-12-24
10:53:00 2 displayName
441322 Default-First-Site-Name\R2DC2 406847 2006-12-24
10:53:00 1 nTSecurityDescriptor
441322 Default-First-Site-Name\R2DC2 406847 2006-12-24
10:53:00 1 name
441322 Default-First-Site-Name\R2DC2 406849 2006-12-24
10:53:00 3 userAccountControl
441322 Default-First-Site-Name\R2DC2 406848 2006-12-24
10:53:00 1 codePage
441322 Default-First-Site-Name\R2DC2 406848 2006-12-24
10:53:00 1 countryCode
441322 Default-First-Site-Name\R2DC2 406848 2006-12-24
10:53:00 1 homeDirectory
441322 Default-First-Site-Name\R2DC2 406848 2006-12-24
10:53:00 1 homeDrive
441322 Default-First-Site-Name\R2DC2 406849 2006-12-24
10:53:00 2 dBCSPwd
441322 Default-First-Site-Name\R2DC2 406848 2006-12-24
10:53:00 1 scriptPath
441322 Default-First-Site-Name\R2DC2 406848 2006-12-24
10:53:00 1 logonHours
441322 Default-First-Site-Name\R2DC2 406848 2006-12-24
10:53:00 1 userWorkstations
441322 Default-First-Site-Name\R2DC2 406849 2006-12-24
10:53:00 2 unicodePwd
441322 Default-First-Site-Name\R2DC2 406849 2006-12-24
10:53:00 2 ntPwdHistory
441322 Default-First-Site-Name\R2DC2 406849 2006-12-24
10:53:00 2 pwdLastSet
441322 Default-First-Site-Name\R2DC2 406848 2006-12-24
10:53:00 1 primaryGroupID
441322 Default-First-Site-Name\R2DC2 406850 2006-12-24
10:53:00 1 supplementalCredentials
441322 Default-First-Site-Name\R2DC2 406848 2006-12-24
10:53:00 1 userParameters
441322 Default-First-Site-Name\R2DC2 406848 2006-12-24
10:53:00 1 profilePath
441322 Default-First-Site-Name\R2DC2 406847 2006-12-24
10:53:00 1 objectSid
441322 Default-First-Site-Name\R2DC2 406848 2006-12-24
10:53:00 1 comment
441322 Default-First-Site-Name\R2DC2 406849 2006-12-24
10:53:00 2 accountExpires
441322 Default-First-Site-Name\R2DC2 406849 2006-12-24
10:53:00 2 lmPwdHistory
441322 Default-First-Site-Name\R2DC2 406847 2006-12-24
10:53:00 1 sAMAccountName
441322 Default-First-Site-Name\R2DC2 406847 2006-12-24
10:53:00 1 sAMAccountType
441322 Default-First-Site-Name\R2DC2 406847 2006-12-24
10:53:00 1 objectCategory
0 entries.
Type Attribute Last Mod Time Originating DC Loc.USN Org.USN Ver
======= ============ ============= ================= ======= ======= ===
Distinguished Name
=============================
[Sun 12/24/2006 11:42:28.25]
G:\>repadmin /showmeta CN=al-testuser1,CN=Users,DC=test,DC=loc r2dc1
22 entries.
Loc.USN Originating DC Org.USN Org.Time/Date
Ver Attribute
======= =============== ========= =============
=== =========
441326 Default-First-Site-Name\R2DC2 406856 2006-12-24
10:53:53 1 objectClass
441326 Default-First-Site-Name\R2DC1 441326 2006-12-24
10:53:54 1 cn
441326 Default-First-Site-Name\R2DC2 406856 2006-12-24
10:53:53 1 instanceType
441326 Default-First-Site-Name\R2DC2 406856 2006-12-24
10:53:53 1 whenCreated
441326 Default-First-Site-Name\R2DC2 406856 2006-12-24
10:53:53 1 nTSecurityDescriptor
441326 Default-First-Site-Name\R2DC2 406856 2006-12-24
10:53:53 1 name
441326 Default-First-Site-Name\R2DC2 406856 2006-12-24
10:53:53 1 userAccountControl
441326 Default-First-Site-Name\R2DC2 406857 2006-12-24
10:53:53 1 codePage
441326 Default-First-Site-Name\R2DC2 406857 2006-12-24
10:53:53 1 countryCode
441326 Default-First-Site-Name\R2DC2 406857 2006-12-24
10:53:53 1 dBCSPwd
441326 Default-First-Site-Name\R2DC2 406857 2006-12-24
10:53:53 1 logonHours
441326 Default-First-Site-Name\R2DC2 406857 2006-12-24
10:53:53 1 unicodePwd
441326 Default-First-Site-Name\R2DC2 406857 2006-12-24
10:53:53 1 ntPwdHistory
441326 Default-First-Site-Name\R2DC2 406857 2006-12-24
10:53:53 1 pwdLastSet
441326 Default-First-Site-Name\R2DC2 406857 2006-12-24
10:53:53 1 primaryGroupID
441326 Default-First-Site-Name\R2DC2 406858 2006-12-24
10:53:53 1 supplementalCredentials
441326 Default-First-Site-Name\R2DC2 406856 2006-12-24
10:53:53 1 objectSid
441326 Default-First-Site-Name\R2DC2 406857 2006-12-24
10:53:53 1 accountExpires
441326 Default-First-Site-Name\R2DC2 406857 2006-12-24
10:53:53 1 lmPwdHistory
441326 Default-First-Site-Name\R2DC2 406856 2006-12-24
10:53:53 1 sAMAccountName
441326 Default-First-Site-Name\R2DC2 406856 2006-12-24
10:53:53 1 sAMAccountType
441326 Default-First-Site-Name\R2DC2 406856 2006-12-24
10:53:53 1 objectCategory
0 entries.
Type Attribute Last Mod Time Originating DC Loc.USN Org.USN Ver
======= ============ ============= ================= ======= ======= ===
Distinguished Name
=============================
[Sun 12/24/2006 11:42:31.05]
G:\>repadmin /showmeta CN=al-testuser2,CN=Users,DC=test,DC=loc r2dc1
24 entries.
Loc.USN Originating DC Org.USN Org.Time/Date
Ver Attribute
======= =============== ========= =============
=== =========
441354 Default-First-Site-Name\R2DC2 406894 2006-12-24
11:26:14 1 objectClass
441354 Default-First-Site-Name\R2DC1 441354 2006-12-24
11:26:15 1 cn
441354 Default-First-Site-Name\R2DC2 406894 2006-12-24
11:26:14 1 instanceType
441354 Default-First-Site-Name\R2DC2 406894 2006-12-24
11:26:14 1 whenCreated
441354 Default-First-Site-Name\R2DC2 406894 2006-12-24
11:26:14 1 displayName
441354 Default-First-Site-Name\R2DC2 406894 2006-12-24
11:26:14 1 nTSecurityDescriptor
441354 Default-First-Site-Name\R2DC2 406894 2006-12-24
11:26:14 1 name
441354 Default-First-Site-Name\R2DC2 406900 2006-12-24
11:26:15 4 userAccountControl
441354 Default-First-Site-Name\R2DC2 406895 2006-12-24
11:26:14 1 codePage
441354 Default-First-Site-Name\R2DC2 406895 2006-12-24
11:26:14 1 countryCode
441354 Default-First-Site-Name\R2DC2 406896 2006-12-24
11:26:15 2 dBCSPwd
441354 Default-First-Site-Name\R2DC2 406895 2006-12-24
11:26:14 1 logonHours
441354 Default-First-Site-Name\R2DC2 406896 2006-12-24
11:26:15 2 unicodePwd
441354 Default-First-Site-Name\R2DC2 406896 2006-12-24
11:26:15 2 ntPwdHistory
441354 Default-First-Site-Name\R2DC2 406898 2006-12-24
11:26:15 3 pwdLastSet
441354 Default-First-Site-Name\R2DC2 406895 2006-12-24
11:26:14 1 primaryGroupID
441354 Default-First-Site-Name\R2DC2 406897 2006-12-24
11:26:15 1 supplementalCredentials
441354 Default-First-Site-Name\R2DC2 406894 2006-12-24
11:26:14 1 objectSid
441354 Default-First-Site-Name\R2DC2 406895 2006-12-24
11:26:14 1 accountExpires
441354 Default-First-Site-Name\R2DC2 406896 2006-12-24
11:26:15 2 lmPwdHistory
441354 Default-First-Site-Name\R2DC2 406894 2006-12-24
11:26:14 1 sAMAccountName
441354 Default-First-Site-Name\R2DC2 406894 2006-12-24
11:26:14 1 sAMAccountType
441354 Default-First-Site-Name\R2DC2 406894 2006-12-24
11:26:14 1 userPrincipalName
441354 Default-First-Site-Name\R2DC2 406894 2006-12-24
11:26:14 1 objectCategory
0 entries.
Type Attribute Last Mod Time Originating DC Loc.USN Org.USN Ver
======= ============ ============= ================= ======= ======= ===
Distinguished Name
=============================
One was created with NET USER, one with ADUC, and one with AdMod. The
accounts aren't configured identically but they are close enough for what
we are talking about her. You will note that unicodePwd value is 1 on the
AdMod example and 2 for the others. This can vary based on whatever tool
is used and how it handles various items. So obviously the version number
is out the window of something to look at because we are doing all of this
to try and reduce assumptions. So looking at all of that data, the first
thing that sticks out to me to use would be to look at the date/time stamp
between objectCategory which cannot be changed and unicodePwd which is the
value we care about. I believe you can safely assume here that if the
values are within seconds of each other the user has not had an
opportunity to set their own password yet.
Helpful?
Merry Christmas to everyone who leans that way, Happy Holidays to everyone
who doesn't.
take care and let's look forward to a good and profitable 2007,
joe
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
From: [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED] On Behalf Of Al Mulnick
Sent: Sunday, December 24, 2006 9:12 AM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Automatic user disable based on criteria
I have the distinct impression that Kamlesh is trying to solve a layer 8
problem with lower layer components. :)
I think it's very interesting that those attributes can show when it was
last changed, but I have to ask: will that show the difference between
what was changed? Is it possible to differentiate between phone number
updates and the helpdesk action described?
I haven't used those attributes to make decisions on in the past, so bear
with me but a quick lookup indicates that those values show that an object
was updated and who updated it. Is that going to be enough information to
make an automated decision? Or do you need some other information to
absolutely identify good from not-so-good targets?
I'm curious if this is something that high-tech should be used to solve
vs. using a different process/low-tech solution.
-ajm
On 12/23/06, joe <[EMAIL PROTECTED]> wrote:
Yes actually adfind can show you metadata... Look at the attributes
msDS-ReplAttributeMetaData
msDS-ReplValueMetaData
I actually have a DCR for AdFind (submitted by me which means it for sure
will get done) that will display that info in a better way than that XML
format they use. When it does, it will also use the binary format of the
attribute so it won't be so slow nor require as much network bandwidth.
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
From: [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED] On Behalf Of Kamlesh Parmar
Sent: Monday, December 18, 2006 12:19 PM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Automatic user disable based on criteria
Hi All,
DFL & FFL : Win2k-Native
DCs : Win2k3-SP1
User accounts are automatically provisioned as enabled with "Change
Password at Next logon". And management wants to disable new accounts
which have not logged into domain within next 7 days of creation. And they
want it to happen automatically.
I have problem at hand as I can't use LastLogonTimeStamp as DFL is not
supportive. I can't connect to each DC and search for lastlogon as number
of DCs are too large, can't go by "whenchanged", as that is generic
attribute, which could get changed for any other attribute also.
Any other attribute would help me?
Currently LDAP filter checks for account created on specific day (say
current day - 7) and whose "Change Password at next logon" is still ticked
i.e. pwdlastset=0
But this doesn't take care of scenario, where users are created on that
same day (current - 7) and logged into network, changed their password,
but around the time of running script, had forgotten password and helpdesk
had resetted their password and set "Change Password at next logon"
I hope I am not confusing you all. :-)
I know, simple solution would be to change criteria to say 15 days, raise
DFL and use LLTS, but I am taking this as a scripting challenge at
Win2k-native DFL.
Hey joe, is there a way to see replication meta data using adfind? ;-)
If yes, I could take a peek at originating date/time for attributes.
--
Kamlesh
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You teach best what you most need to learn.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
