Having lived in the real world for only a few weeks now, I can appreciate that hiring managers and HR don't always take the time to complete the paperwork and that people don't always do what they say they will. I can. Honest. But that doesn't mean that the process is where it needs to be, right?
<queue the evil booming laughter> There are ways to train and strongly encourage hiring managers and hr personnel to complete the loop. Process methods are possible. Incentives (using the honey vs. the vinegar) can often help as well. In fact, I argue that using these incentives, any other method would likely be obsolote or not worth the effort to implement. Well, except to ensure that policy is being enforced, but that's a different thread. There are ways to create closed-loop process such that it's not possible to have the exist longer than needed and to put that process on the responsible manager. It's possible, but I haven't heard any thought being used to see if that fits in your situation. Not to say you haven't just to say that I haven't heard it if so. Andrew, I appreciate you taking the time to respond with scenario you mentioned. I've seen similar and I understand what you mean. I think joe really put a lot of thought into the answer(s) he gave and I'm not discounting the idea of using that data to make decisions. I'm just saying that there are times to solve with technology and times to solve with layer-8 process adjustments. I'm not convinced, based on the information given, that this problem best solved by technology alone and that there's likely a hybrid technology-layer8 solution to this issue. I additionally think there's more to this and that although one may get the initial results sought, you'll find that over time this is not a done issue. There'll be more to this at some point from what I've seen so far and to me, that seems as if we haven't done all we can to define and solve the issue. I'm selfish and realize that would mean that more time than expected and budgeted will eventually be spent to fix the issue. Hopefully I'm wrong though. -ajm On 12/26/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
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 [email protected] To [email protected] 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] <[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* <http://www.joeware.net/win/ad3e.htm> ------------------------------ *From:* [EMAIL PROTECTED]<[EMAIL PROTECTED]>[mailto: * [EMAIL PROTECTED] <[EMAIL PROTECTED]>] *On Behalf Of *Al Mulnick* Sent:* Sunday, December 24, 2006 9:12 AM* To:* [EMAIL PROTECTED] <[email protected]>* 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] <[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* <http://www.joeware.net/win/ad3e.htm> ------------------------------ *From:* [EMAIL PROTECTED]<[EMAIL PROTECTED]>[mailto: [EMAIL PROTECTED] <[EMAIL PROTECTED]>] *On Behalf Of *Kamlesh Parmar* Sent:* Monday, December 18, 2006 12:19 PM * To:* [EMAIL PROTECTED] <[email protected]>* 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. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
