PASSWD_CANT_CHANGE bit in userAccountControl

[JRB]

Following the discussion on how to enable/disable a user changing
their own password several weeks back, I now have the sample code for
modifying the ACEs working. But the PASSWD_CANT_CHANGE bit in
userAccountControl seems to be unused. Modifying the ACEs whether via
the sample code or ADUC does not result in this bit being set when the
rights are revoked, and ADSI does not allow this bit to be set
directly by the application changing the ACEs. This is under W2003
server enterprise edition. If I toggle "password never expires" in
ADUC I can see the bit change in userAccountControl immediately. Under
what circumstances if any is this bit used? Or is it one of those
unreliable features of windows where the value might get updated in
the next week or two? I would like to avoid having to read the ACEs to
determine this setting, due to the slowness of reading
"ntSecurityDescriptor".

Thanks in advance, John

[Joe Kaplan]

Did you try checking the msDS-User-Account-Control-Computed attribute to see
if the flag is set properly there?

There are some flags on userAccountControl in AD that just don't work such
as the lockout flag and this one. They are included for backwards
compatibility with NT4 (which uses the same enum), but the directory
supports those functions in a different way. However, the computed
attribute is supposed to help with that. I'm just not sure if it supports
the "user cannot change password setting.

It may be necessary to check the security descriptor directly.

Joe K.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--
"JRB" <jo...@jrbsoftware.com> wrote in message
news:1179271327.8...@o5g2000hsb.googlegroups.com...

[Richard Mueller [MVP]]

I have not used the ADS_UF_PASSWD_CANT_CHANGE bit of userAccountControl
because it is unreliable. However, I have configured several users so they
cannot change their password, and none have this bit set. The documentation
says this bit can be read, but I think that is mistaken. I don't know how
ADUC determines this setting. The only way I know is to read the security
descriptor.

--
Richard Mueller
Microsoft MVP Scripting and ADSI
Hilltop Lab - http://www.rlmueller.net
--

"Joe Kaplan" <joseph....@removethis.accenture.com> wrote in message
news:egWLOh9l...@TK2MSFTNGP03.phx.gbl...

[Joe Richards [MVP]]

ADUC reads the Security Descriptor.

--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net

---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm

[Joe Kaplan]

Do you know if that flag is supported in the computed attribute or does the
computed attribute only support lockout and password expired? I don't have
a handy way to test it right now.

Thanks!

Joe K.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--

"Joe Richards [MVP]" <humore...@hotmail.com> wrote in message
news:ecNlylLm...@TK2MSFTNGP06.phx.gbl...

[JRB]

Thanks for your answers. My testing yesterday showed no change in the
value of the computed attribute when a user's ability to change their
password was revoked. Or maybe I should say "no immediate change". I
recall reading somewhere that there can be considerable delays before
some computed values are updated - is that correct?

John

On May 18, 8:17 am, "Joe Kaplan"

<joseph.e.kap...@removethis.accenture.com> wrote:
> Do you know if that flag is supported in the computed attribute or does the
> computed attribute only support lockout and password expired? I don't have
> a handy way to test it right now.
>
> Thanks!
>
> Joe K.
>
> --
> Joe Kaplan-MS MVP Directory Services Programming
> Co-author of "The .NET Developer's Guide to Directory Services Programming"http://www.directoryprogramming.net
> --

> "Joe Richards [MVP]" <humorexpr...@hotmail.com> wrote in messagenews:ecNlylLm...@TK2MSFTNGP06.phx.gbl...

>
>
>
> > ADUC reads the Security Descriptor.
>
> > --
> > Joe Richards Microsoft MVP Windows Server Directory Services
> > Author of O'Reilly Active Directory Third Edition
> >www.joeware.net
>
> > ---O'Reilly Active Directory Third Edition now available---
>
> > http://www.joeware.net/win/ad3e.htm
>
> > Richard Mueller [MVP] wrote:
> >> I have not used the ADS_UF_PASSWD_CANT_CHANGE bit of userAccountControl
> >> because it is unreliable. However, I have configured several users so
> >> they cannot change their password, and none have this bit set. The
> >> documentation says this bit can be read, but I think that is mistaken. I
> >> don't know how ADUC determines this setting. The only way I know is to

> >> read the security descriptor.- Hide quoted text -
>
> - Show quoted text -

[Joe Kaplan]

In this case, no, there should not be. I believe you are seeing the
expected result which is that the computed attribute supports the "locked
out" and "password expired" states, but not "user cannot change password".

It would appear you have to read the DACL. Given that this is what ADUC
does according to Joe R., I'm not surprised.

As usual, the documentation could be a little more helpful here. I'm
ashamed to say that we didn't even remember to cover this setting in ch 10
of our book. I've never been in a situation where I wanted to use that flag
and just never thought about it. Oh well. This has been a good education
for me.

Joe K.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--

"JRB" <jo...@jrbsoftware.com> wrote in message

news:1179438482.7...@o5g2000hsb.googlegroups.com...

[Joe Richards [MVP]]

It is my understanding that that computed value is only for lockout and
expiration. I could go chase the source I guess but I would not be
surprised to not see can't change password.

--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net

---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm

[Joe Richards [MVP]]

There would be no delay on this other than replication, it would be
computed on the spot.

I am actually trying to visualize ANY constructed attributes that would
have delay. I can't think of one off the top of my head, they should all
updated immediately. There are things like universal group caching etc
that will have a delay but they aren't constructed attributed based on
immediate DS relationships, it is info being synced from one DC to
another through a special process.

--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net

---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm

[Joe Richards [MVP]]

I just verified the source (used K3 SP2). The only things checked and
set are account expiration and account lockout. You can take that as
authoritative.

[Joe Kaplan]

Thanks for checking. I accidentally let my card expire and have to mail it
back manually for renewal. I'm an idiot. :)

Joe K.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--
"Joe Richards [MVP]" <humore...@hotmail.com> wrote in message

news:uBCCpEPm...@TK2MSFTNGP02.phx.gbl...

[Joe Richards [MVP]]

Ah that sucks. That is how it used to be... I bitched and bitched and
bitched until they came up with an online method. :)

[JRB]

Thanks Joe, I guess this is potential material for the second edition!

Re my comments on delayed updates - I just remembered what it was that
inspired that comment. I had my wires crossed a little, I had read
that the lastLogonTimeStamp is replicated only every 14 days because
"replicating more often could generate a large amount of replication
traffic". A somewhat weak excuse given eDirectory manages to replicate
the last login time to all servers holding a replica within seconds of
a login, and with minimal traffic.

John

On May 18, 10:49 am, "Joe Kaplan"

<joseph.e.kap...@removethis.accenture.com> wrote:
> In this case, no, there should not be. I believe you are seeing the
> expected result which is that the computed attribute supports the "locked
> out" and "password expired" states, but not "user cannot change password".
>
> It would appear you have to read the DACL. Given that this is what ADUC
> does according to Joe R., I'm not surprised.
>
> As usual, the documentation could be a little more helpful here. I'm
> ashamed to say that we didn't even remember to cover this setting in ch 10
> of our book. I've never been in a situation where I wanted to use that flag
> and just never thought about it. Oh well. This has been a good education
> for me.
>
> Joe K.
>
> --
> Joe Kaplan-MS MVP Directory Services Programming
> Co-author of "The .NET Developer's Guide to Directory Services Programming"http://www.directoryprogramming.net

> --"JRB" <j...@jrbsoftware.com> wrote in message

> >> - Show quoted text -- Hide quoted text -

[Paul Williams [MVP]]

If you don't mind me butting in, there's probably a bit of a difference
between AD and eDirectory here (I know there are others, but I won't go down
that road having no experience with eDirectory). Firstly, you can replicate
that attribute with every change if you like [1], it's just not recommended,
and the reason is that all types of logon update that attribute (except
simple bind [in AD] IIRC -not 100% sure, will have to check), as opposed to
just interactive logon. Therefore, any time you get use a Kerberos ticket
to access a remote service, you logon. Perhaps eDirectory is only logging
interactive logon? Maybe you can clarify...

[1] ADAM only. One day is the minimum for AD IIRC.

Note also. The attribute replicates normally. Internally, the DS doesn't
update it everytime, it uses a rather complex algorith based on the value of
msDS-LogonTimeSyncInterval minus a random interval between 0 and 5.

--
Paul Williams
Microsoft MVP - Windows Server - Directory Services
http://www.msresource.net | http://forums.msresource.net