Yeah I was thinking about forcing pwdLastSet to 0 or forcing an account expiration (versus password expiration) with the accountExpires attribute. The former can be bypassed if someone knows the password, they can change the old password and be up and running. The other would require an admin interaction.
joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joe Kaplan Sent: Monday, August 21, 2006 5:46 PM To: [email protected] Subject: Re: [ActiveDir] UAC Question That's a good explanation. I don't see how you can lock them out programmatically though. The mechanism just isn't designed to do that. You'd have to force bad auth attempts on them constantly. If you can't disable the AD account, what if you expired it? That would prevent login too, right? You could just set the expiration date back to an unexpired value when you need to. Just a thought... Joe K. ----- Original Message ----- From: David Aragon To: [email protected] Sent: Monday, August 21, 2006 3:14 PM Subject: RE: [ActiveDir] UAC Question I think I need to expand the picture here to provide more clarity. At the top of our tree we have openLDAP which we refer to as the Enterprise and which is the authoritative source for all credentials. That feeds several sub-systems, including Active Directory, email, SMB, etc. We have internally developed connectors to provide each sub-system the appropriate user information including passwords (when required by that sub-system). This has afforded us a working single-sign on for multiple platforms (Windows, MAC, & Linux). Users can go to any computer, any platform, and their credentials are valid (though there might be local restrictions). Users go to a single point to change their password and that change is then appropriately encrypted and transmitted to each sub-system in a form that is best for that sub-system. This all works quite well, however, because of this we can not change the user's password in AD without causing a break between the Enterprise and AD user objects. Forcing a change in the password of a user object at the Enterprise level would cut the user off from their email, personal network shares, etc. A couple of years ago the telephony group paid a LOT of money for this software (let me repeat here that I was not involved until recently). A few months after the purchase, the company was bought by a larger company who apparently didn't bother keeping any of the original developers, programmers, etc. though they continue to "support" the software. We have been told on numerous occasions, however, that because we have an unconventional setup, we are virtually on our own and no one wants to cough up another big chunk of money to replace the software. The software requires a voice mailbox be tied to an active Directory user account, but once created, the only check that is made is if the AD user account is enabled or disabled. I recently complained that we were leaving a possible security hole by not doing something with these accounts and, as typically happens, I was tasked with coming up with an appropriate solution. At the time, it seemed the easiest path to follow would be to set the account lockout which would prevent the user from logging into the vast majority of systems, but still allow them the ability to get their email (from off campus), vm (from off campus or on campus), etc. This is still the path I'm pursuing. David Aragon From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier, Guido Sent: Monday, August 21, 2006 10:53 AM To: [email protected] Subject: RE: [ActiveDir] UAC Question Adding a dummy workstation will hinder the user to logon interactively - this could be all you want to achieve. But it won't hinder network logons - this may be undesired. Another thought - if the users aren't really using their AD account, couldn't you just change the PW to some complex dummy pwd? This would ensure that the user wouldn't be able to use the account for any AD authentication - until they come back from their sabbatical and the helpdesk resets the pwd for them. Also, I'd check with the application vendor, if you can't configure it to use an attribute other than the disabled flag to see if the account should be voicemail enabled or not. This would give you much more granular control over the matter - you could disable the AD account (which it seems is really what you want to do) while still leaving the voicemail intact. /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick Sent: Monday, August 21, 2006 6:57 PM To: [email protected] Subject: Re: [ActiveDir] UAC Question Why are the last two groups treated differently than the others? You may want to consider a different approach, such as changing to the workstations that they can logon to or expiring the account. On 8/21/06, David Aragon <[EMAIL PROTECTED]> wrote: Al, Thank you for your response, I will try to elaborate, but first, let me start by saying that I was not invited to participate in this application's selection, testing, or acceptance. One day it just showed up. That said ... The software we use for VOIP uses its own db for storing messages. It was supposed to be AD aware. It's not. It is (barely) LDAP aware. I've found that when a user checks their voice mail (after they enter in their pass code) the program only checks to see if their AD account is enabled or disabled. We do have a password policy that does exactly what you describe (locks users out for some period of time after x invalid attempts). We have also given the senior Help Desk staff the ability to unlock an account under certain circumstances. We have some (a couple hundred) accounts that exist to handle the section or group vm for those areas where individuals that share a phone number. These, I have identified and developed methods that prevent them from being used as login accounts. I have also found that there are users that do not have a computer and never use a computer, but they have vm enabled on their phone. We also have users that take sabbaticals for 6 months to a year. It is these last two groups I was hoping to address with setting the UAC account lockout. Politically I can not disable the accounts. I have tried to add the accounts to the permanent lockout list which works, but when the last groups returns it takes time for us to remove them from the list. Again politically unacceptable. This makes us having the ability to set the account lockout very appealing. What I was looking for was a way to set the lockout bit. It was previously explained that the bit can not be set directly, but that by setting the lockoutTime to some non-zero value the account is locked (though I've found that the bit is not always set). My current research and testing is moving along that path. David Aragon From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] On Behalf Of Al Mulnick Sent: Monday, August 21, 2006 6:33 AM To: [email protected] Subject: Re: [ActiveDir] UAC Question This part troubles me: "(for example it will prevent a user from logging into a system, but not prevent them from getting their voicemail)." Can you expand on that? To my thinking, if the account is locked out, then the user should not be able to use it. Period. End of story. No exceptions. Locked out functionality is there as a precaution to prevent misuse of the identity (ok, account.) Why would you want to subvert that? What benefit that cannot be achieved in another manner? Again, to my way of thinking, there is no reason you would ever want to mess with it in your day to day. A better option would be to set it to automatically clear after a certain period which would prevent hackers, crackers, and script kiddies (side note: set it to something that would cause a cracker to take longer to realistically crack than the password change cycle) from obtaining the passwords of the accounts. For example, .5 hours lockout after x number of attempts means that for every x number of attempts, anyone trying to programmatically trying to guess passwords would have to pause for .5 hours before resumption. If you have hundreds of thousands of possible passwords and combinations, that can make the time to crack longer than the password change interval if you design it that way. My initial take on this is that you're trying to do something and that there's a better/more supported way to accomplish it. Am I missing something? On 8/2/06, David Aragon <[EMAIL PROTECTED] > wrote: http://support.microsoft.com/kb/305144/ discusses the various property flags for the UserAccountControl (UAC). I have tried to set different flags using LDP, ADSIEdit, and vbScript. One flag in particular is giving me a lot of grief, LOCKOUT. I can clear the bit, but can not set it. This is useful to set for a number of reasons (for example it will prevent a user from logging into a system, but not prevent them from getting their voicemail). Is this normal? Can it be set and if so, how? Is it dependent on other settings (ex. lockoutTime) to be set to remain set? David Aragon List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx
