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
