Thank you all. I will give a serious look at account expiration, that might work also. Again, I was originally looking at account lockout because the tools and permissions already exist to unlock an account by certain help desk members and I wouldn't have to provide additional tools and training.
David Aragon > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of joe > Sent: Monday, August 21, 2006 3:19 PM > To: [email protected] > Subject: RE: [ActiveDir] UAC Question > > 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 > 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
