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.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
