userAccountControl

  • Thread starter Thread starter RF
  • Start date Start date
R

RF

Hi,

I am using the DirectoryServices class in .NET and would like to find some
information regarding "userAccountControl".

I'm adding a user atttributes (C#):
user.Properties["userAccountControl"].Add(512); // account is
enabled
user.Properties["userAccountControl"].Add(514); // account is
disabled

I stumbled across these values while enumerating other preloaded users.
Where can I find other values to set for "userAccountControl".

Also, how can I do the following (correct me if I wrong)
user.Properties["accountExpires"].Add(new Date()); // is this right?
user.Properties["logonHours"}.Add(new Time()); // is this right?
user.Properties["accountLocked"].Add(true); // is this right?

Also, to reset the password of a user, do I call the setpassword again?
user.Invoke("SetPassword",new object[]{password});


Thanks a million,

Randy F.
 
Thank Joe for your help.

For the "accountLocked", what I meant was how I can programmatically lock
and unlock an account thru DirectoryServices.

TIA,
Randy

Joe Kaplan (MVP - ADSI) said:
The userAccountControl enum values are defined here:

http://msdn.microsoft.com/library/d...netdir/adsi/ads_user_flag_enum.asp?frame=true

You can create your own enum in C#, set the values directly or import the
actual enum type from the activeds.dll COM object by setting a reference to
it or using tlbimp.

Here is a creating users sample for reference:

http://msdn.microsoft.com/library/d...us/netdir/netds/creating_users.asp?frame=true

Make sure you call CommitChanges on a new object before trying to call
SetPassword for the first time and make sure you have SSL set up correctly
on your DC to avoid having problems with this method as SetPassword wants a
128 bit SSL connection under the hood as it primary protocol choice.

http://msdn.microsoft.com/library/d.../netds/managing_user_passwords.asp?frame=true

Regarding setting accountExpires, that is an INTEGER8 AD datatype, so it is
not set with a date value. This shows how to manipulate them:

http://msdn.microsoft.com/library/d...ds/large_integer_property_type.asp?frame=true

Note that INTEGER8 types that contain dates are actually stored as Windows
FileTime structures, so you can use the .NET DateTime.FromFileTime method to
convert them directly.

logonHours is a binary (octet string) data type, so you need to pass in the
appropriate byte array to set that value. I'm not sure what the syntax for
that is.

accountLocked is not an AD attribute (at least in my schema).

HTH,

Joe K.


RF said:
Hi,

I am using the DirectoryServices class in .NET and would like to find some
information regarding "userAccountControl".

I'm adding a user atttributes (C#):
user.Properties["userAccountControl"].Add(512); // account is
enabled
user.Properties["userAccountControl"].Add(514); // account is
disabled

I stumbled across these values while enumerating other preloaded users.
Where can I find other values to set for "userAccountControl".

Also, how can I do the following (correct me if I wrong)
user.Properties["accountExpires"].Add(new Date()); // is this right?
user.Properties["logonHours"}.Add(new Time()); // is this right?
user.Properties["accountLocked"].Add(true); // is this right?

Also, to reset the password of a user, do I call the setpassword again?
user.Invoke("SetPassword",new object[]{password});


Thanks a million,

Randy F.
 
Gotcha. You need to set the ADS_UF_LOCKOUT flag in userAccountControl
enumerated value to "on". That will cause the account to be locked (or
unlocked for unset).

Joe K.
 
Correction: See Richard Mueller's post in microsoft.public.adsi.general
today under "WinNT-provider doesn't use supplied credentials". I believe
that flag doesn't actually work correctly and you need to do something
fancier. For some reason I always forget this because I never do this
programmatically.

Sorry,

Joe K.
 
Thanks again,

Randy


Joe Kaplan (MVP - ADSI) said:
Correction: See Richard Mueller's post in microsoft.public.adsi.general
today under "WinNT-provider doesn't use supplied credentials". I believe
that flag doesn't actually work correctly and you need to do something
fancier. For some reason I always forget this because I never do this
programmatically.

Sorry,

Joe K.
 
Hi,

The IsAccountLocked property method (with the LDAP provider) returns the
same value whether the account is locked or not. However, this property
method can be used to unlock the account. Similarily, the userAccountControl
flag (with the mask ADS_UF_LOCKOUT = &H10) cannot be used to reveal if the
account is locked. Instead, when the account is locked out, the badPwdCount
attribute of the user object becomes equal to the domain setting for maximum
attempts (lockoutThreshold) and the lockoutTime attribute has a value
(corrsponding to the date and time the account was locked out). If the
domain lockout reset window (lockoutDuration) expires, the account is no
longer locked out, but no attribute values change for the user object
(exposed by the LDAP provider). The only way to tell if the account is still
locked out is to add the domain lockoutDuration to the user lockoutTime,
convert to a date, and compare with Now to see if the duration has expired.

If the account is unlocked manually, badPwdCount is set to 0 and lockoutTime
is set to 0. If instead, the reset duration (the domain lockoutDuration)
expires, the account is no longer locked, but badPwdCount and lockoutTime
are unchanged. However, when the user logs on successfully, both of these
attributes are set to 0.

I have just tested and I find that you can manipulate the userAccountControl
attribute (with the LDAP provider) to unlock the account. The behaviour
seems strange, but it works. As you know, if you test userAccountControl
with the bit mask you find it never changes. If you use ADSI Edit to
monitor, you see that userAccountControl never changes when the account gets
locked out, or when you unlock it. However, you can toggle the bit with
code. When the account is locked out and you toggle the ADS_UF_LOCKOUT bit
the attribute value changes and the account remains locked out. If you then
toggle the bit again, the attribute returns to it's original value, but the
account is now unlocked. Magic. Also, the badPwdCount and lockoutTime
attributes get zero'ed.

Obviously, the userAccountControl attribute has some kind of bug.
 
I've got W2k3, but have not yet installed it. I only tested on W2k. I don't
remember seeing in any reports that this was fixed.

Richard
 
Interesting. Thanks for the detailed investigation there. I'm going to
save that one.

Just out of curiosity, did you happen to test that on Win2K3 AD, or just
Win2K? I wonder if this is fixed or if the behavior is maintained for
backward compatibility. I don't have a Win2K3 AD to play with yet, so I
don't have an easy way to see.

Thanks again,

Joe K.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Back
Top