Al et. al.,
Yes, I definitely have some additional avenues to look down. The
original plan was to set the lockout bit, that didn't work. Next was to
set the lockoutTime to some future point in time with the anticipation that the
lockout bit will set itself, I have not had time yet to test that, but the code
had been written. Because of Security logging, etc. I had, early on, ruled
out hitting the account with a barrage of bad passwords to force the
lockout. Other things we have watching the network would have
misinterpreted it as an attack.
Should setting the lockoutTime fail then the next path is to test
accountExpires and finally setting LogonHours to 0 (an off-line
suggestion). Should either of the latter two suggestions work, this will
require developing some additional tools and providing training on their
use.
Thank you all for
your suggestions. You helped turn a dead end path into a multilane
road. We shall see where it takes us.
David Aragon
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick
Sent: Tuesday, August 22, 2006 6:22 AM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] UAC QuestionDavid, I think you just about have to come up with another method. You mentioned earlier that your account lockout policies will unlock the account after a period of time meaning that, as JoeK pointed out, you'd have to constantly hit the account with bad attempts. That would certainly negate any kind of logging/security mechanisms in place to try and find attempts to crack the passwords. It would be lost in the designed attempts, so no point in even trying, right?Anyhow, hopefully the conversations have stimulated some thoughts. Just keep in mind that you're trying to build around a problem that shouldn't even exist. You won't want to perpetuate that thinking or the associated problems if you can help it. Now might be a good time to put some ground work in that guides the next solutions down the road.Good luck.Al
On 8/21/06, David Aragon <[EMAIL PROTECTED]> wrote: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: ActiveDir@mail.activedir.org
> 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: ActiveDir@mail.activedir.org
> 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: ActiveDir@mail.activedir.org
> 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: ActiveDir@mail.activedir.org
> 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: ActiveDir@mail.activedir.org
> 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: ActiveDir@mail.activedir.org
> 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
