RE: [ActiveDir] permissions to only disable an AD user account
Lots of extended rights can be done in a delegated manner at any level of the NC, off the top of my head think about Change Password and Reset Password. As for Eric's comments on the tying it to a functional level, I think that makes sense unless it is possible to back port the fix into older OSes at which point you can say the functionality will be on any machine you put this hotfix on or maybe do hotfix plus an AD Setting like the anonymous access setting. - http://www.joeware.net (download joeware) http://www.cafeshops.com/joewarenet (wear joeware) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of GRILLENMEIER,GUIDO (HP-Germany,ex1) Sent: Sunday, March 28, 2004 4:42 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] permissions to only disable an AD user account and once you've got the method for updating that attribute in place, you'd still need to add a way to grant permissions in AD to allow to use the method - right? I could imagine, that this would happen via additional Extended Rights, similar to other new Rights that have already been added in Win 2003, such as: - Unexpire-Password (allows a user to restore an expired password for a user object) - Update-Password-Not-Required-Bit (allows a user to enable or disable the "password not required" setting for user objects) The downside currently is, that I believe these Extended Rights can only be set on the NC level, i.e. for a whole domain. Would be good to get allow managing them on the OU or even Object level... But I haven't played around with them too much - maybe it already works today. Anybody know for sure? /Guido P.S.: > So what do we do with LVR when you go FFL = 1 or 2? We say old group memberships are intact not-LVR'd but with no real downsides as a result... < ... appart from recovery for group-memberships for deleted objects ;-) -Original Message- From: Eric Fleischman [mailto:[EMAIL PROTECTED] Sent: Sonntag, 28. März 2004 16:57 To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] permissions to only disable an AD user account So long as we can agree that you'll either have an inconsistent admin experience or a functional level dependency, that'll work, although I wouldn't like it as much as some other options. ;) Here's an option I like: tie it to functional level, but in the same way we do LVR now. So what do we do with LVR when you go FFL = 1 or 2? We say old group memberships are intact not-LVR'd but with no real downsides as a result, new group memberships are LVR'd and you can convert with a crazy script if you so choose. Could we take a similar approach here? Maybe, I haven't thought it all the way through, but perhaps we could. ~Eric -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Sunday, March 28, 2004 8:16 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] permissions to only disable an AD user account Actually I was thinking of the msds-someotherattribute as being "method" type attribs [1] instead of actually storing values. Since we are already in the situation where userAccountControl is authoritative for that info. Don't start duplicating it in other attribs, instead use a method attrib that you can modify bits of the useraccountcontrol with. Actually I see the benefits both ways but agree on overhead (churn) having to keep changing those attribs back and forth and such on all machines around the domain/GC environment. Possibly the additional attributes are the generated ones but allow modification in such a way that the mod goes straight back to useraccountcontrol. Then the useraccountcontrol is the only thing being replicated which puts us right back where we are today except you can delegate who can change the bits. [1] By this I mean of course operational attributes like becomeRidMaster, etc. Of course that brings up the discussion, can you secure those operational attributes without tapping the attribute that they end up modifying? I am honestly not sure. - http://www.joeware.net (download joeware) http://www.cafeshops.com/joewarenet (wear joeware) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman Sent: Saturday, March 27, 2004 10:46 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] permissions to only disable an AD user account Oh, I misunderstood you I think Joe. You mean when you update msds-someotherattribute it does the userAccountControl for you as well and vice-versa as well? If so, yea, only DCs with a writable copy of the NC would need that change you described as GCs that do not have a writeable copy of the NC would be read-only anyway. However, we would probably want to add all of these new attributes to the PAS ..that's a lot of churn if you haven't gone 2k03 yet. ~Eric -Ori
RE: [ActiveDir] permissions to only disable an AD user account
and once you've got the method for updating that attribute in place, you'd still need to add a way to grant permissions in AD to allow to use the method - right? I could imagine, that this would happen via additional Extended Rights, similar to other new Rights that have already been added in Win 2003, such as: - Unexpire-Password (allows a user to restore an expired password for a user object) - Update-Password-Not-Required-Bit (allows a user to enable or disable the "password not required" setting for user objects) The downside currently is, that I believe these Extended Rights can only be set on the NC level, i.e. for a whole domain. Would be good to get allow managing them on the OU or even Object level... But I haven't played around with them too much - maybe it already works today. Anybody know for sure? /Guido P.S.: > So what do we do with LVR when you go FFL = 1 or 2? We say old group memberships are intact not-LVR'd but with no real downsides as a result... < ... appart from recovery for group-memberships for deleted objects ;-) -Original Message- From: Eric Fleischman [mailto:[EMAIL PROTECTED] Sent: Sonntag, 28. März 2004 16:57 To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] permissions to only disable an AD user account So long as we can agree that you'll either have an inconsistent admin experience or a functional level dependency, that'll work, although I wouldn't like it as much as some other options. ;) Here's an option I like: tie it to functional level, but in the same way we do LVR now. So what do we do with LVR when you go FFL = 1 or 2? We say old group memberships are intact not-LVR'd but with no real downsides as a result, new group memberships are LVR'd and you can convert with a crazy script if you so choose. Could we take a similar approach here? Maybe, I haven't thought it all the way through, but perhaps we could. ~Eric -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Sunday, March 28, 2004 8:16 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] permissions to only disable an AD user account Actually I was thinking of the msds-someotherattribute as being "method" type attribs [1] instead of actually storing values. Since we are already in the situation where userAccountControl is authoritative for that info. Don't start duplicating it in other attribs, instead use a method attrib that you can modify bits of the useraccountcontrol with. Actually I see the benefits both ways but agree on overhead (churn) having to keep changing those attribs back and forth and such on all machines around the domain/GC environment. Possibly the additional attributes are the generated ones but allow modification in such a way that the mod goes straight back to useraccountcontrol. Then the useraccountcontrol is the only thing being replicated which puts us right back where we are today except you can delegate who can change the bits. [1] By this I mean of course operational attributes like becomeRidMaster, etc. Of course that brings up the discussion, can you secure those operational attributes without tapping the attribute that they end up modifying? I am honestly not sure. - http://www.joeware.net (download joeware) http://www.cafeshops.com/joewarenet (wear joeware) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman Sent: Saturday, March 27, 2004 10:46 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] permissions to only disable an AD user account Oh, I misunderstood you I think Joe. You mean when you update msds-someotherattribute it does the userAccountControl for you as well and vice-versa as well? If so, yea, only DCs with a writable copy of the NC would need that change you described as GCs that do not have a writeable copy of the NC would be read-only anyway. However, we would probably want to add all of these new attributes to the PAS ..that's a lot of churn if you haven't gone 2k03 yet. ~Eric -Original Message- From: Eric Fleischman Sent: Saturday, March 27, 2004 9:33 PM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] permissions to only disable an AD user account You "actually" agree? Yee of little faith! :) The hotfix and schema update thing you toss in would need to be forest-wide (of course schema is implicitly, but fix would need to be as well) as userAccountControl is part of the PAS. It is, IMHO, not a solution to this problem. Say we need to get rid of this attribute, sure, but making it constructed isn't the way. True, 24 hours back is safer, but if you're making the change on a single dc if you bind to that dc and look at the time on it on RootDSE I would think you are safe. I'd need to think about that a bit more though, never thought about all of the caveats here. ~Eric
RE: [ActiveDir] permissions to only disable an AD user account
So long as we can agree that you'll either have an inconsistent admin experience or a functional level dependency, that'll work, although I wouldn't like it as much as some other options. ;) Here's an option I like: tie it to functional level, but in the same way we do LVR now. So what do we do with LVR when you go FFL = 1 or 2? We say old group memberships are intact not-LVR'd but with no real downsides as a result, new group memberships are LVR'd and you can convert with a crazy script if you so choose. Could we take a similar approach here? Maybe, I haven't thought it all the way through, but perhaps we could. ~Eric -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Sunday, March 28, 2004 8:16 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] permissions to only disable an AD user account Actually I was thinking of the msds-someotherattribute as being "method" type attribs [1] instead of actually storing values. Since we are already in the situation where userAccountControl is authoritative for that info. Don't start duplicating it in other attribs, instead use a method attrib that you can modify bits of the useraccountcontrol with. Actually I see the benefits both ways but agree on overhead (churn) having to keep changing those attribs back and forth and such on all machines around the domain/GC environment. Possibly the additional attributes are the generated ones but allow modification in such a way that the mod goes straight back to useraccountcontrol. Then the useraccountcontrol is the only thing being replicated which puts us right back where we are today except you can delegate who can change the bits. [1] By this I mean of course operational attributes like becomeRidMaster, etc. Of course that brings up the discussion, can you secure those operational attributes without tapping the attribute that they end up modifying? I am honestly not sure. - http://www.joeware.net (download joeware) http://www.cafeshops.com/joewarenet (wear joeware) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman Sent: Saturday, March 27, 2004 10:46 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] permissions to only disable an AD user account Oh, I misunderstood you I think Joe. You mean when you update msds-someotherattribute it does the userAccountControl for you as well and vice-versa as well? If so, yea, only DCs with a writable copy of the NC would need that change you described as GCs that do not have a writeable copy of the NC would be read-only anyway. However, we would probably want to add all of these new attributes to the PAS ..that's a lot of churn if you haven't gone 2k03 yet. ~Eric -Original Message- From: Eric Fleischman Sent: Saturday, March 27, 2004 9:33 PM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] permissions to only disable an AD user account You "actually" agree? Yee of little faith! :) The hotfix and schema update thing you toss in would need to be forest-wide (of course schema is implicitly, but fix would need to be as well) as userAccountControl is part of the PAS. It is, IMHO, not a solution to this problem. Say we need to get rid of this attribute, sure, but making it constructed isn't the way. True, 24 hours back is safer, but if you're making the change on a single dc if you bind to that dc and look at the time on it on RootDSE I would think you are safe. I'd need to think about that a bit more though, never thought about all of the caveats here. ~Eric -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Saturday, March 27, 2004 8:47 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] permissions to only disable an AD user account Cool and I actually agree. The constructed causes all sorts of issues, breaks all sorts of legacy code, especially anything that would search. So doing the additional method type attribs that would update useraccountcontrol on the user's behalf should be something that could work though obviously it wouldn't be something you could all of a sudden do on a current DC (2K or K3) without a handy dandy hotfix and schema update. One note on the "now" perspective with the DC... That would be now in one TZ. May be 10 hours off for another. I would still recommend setting it to now-24 hours at the least. - http://www.joeware.net (download joeware) http://www.cafeshops.com/joewarenet (wear joeware) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman Sent: Saturday, March 27, 2004 3:29 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] permissions to only disable an AD user account While I (personally, speaking in a position of no power over this) tend to agree that userAcco
RE: [ActiveDir] permissions to only disable an AD user account
Oh, I misunderstood you I think Joe. You mean when you update msds-someotherattribute it does the userAccountControl for you as well and vice-versa as well? If so, yea, only DCs with a writable copy of the NC would need that change you described as GCs that do not have a writeable copy of the NC would be read-only anyway. However, we would probably want to add all of these new attributes to the PAS ..that's a lot of churn if you haven't gone 2k03 yet. ~Eric -Original Message- From: Eric Fleischman Sent: Saturday, March 27, 2004 9:33 PM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] permissions to only disable an AD user account You "actually" agree? Yee of little faith! :) The hotfix and schema update thing you toss in would need to be forest-wide (of course schema is implicitly, but fix would need to be as well) as userAccountControl is part of the PAS. It is, IMHO, not a solution to this problem. Say we need to get rid of this attribute, sure, but making it constructed isn't the way. True, 24 hours back is safer, but if you're making the change on a single dc if you bind to that dc and look at the time on it on RootDSE I would think you are safe. I'd need to think about that a bit more though, never thought about all of the caveats here. ~Eric -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Saturday, March 27, 2004 8:47 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] permissions to only disable an AD user account Cool and I actually agree. The constructed causes all sorts of issues, breaks all sorts of legacy code, especially anything that would search. So doing the additional method type attribs that would update useraccountcontrol on the user's behalf should be something that could work though obviously it wouldn't be something you could all of a sudden do on a current DC (2K or K3) without a handy dandy hotfix and schema update. One note on the "now" perspective with the DC... That would be now in one TZ. May be 10 hours off for another. I would still recommend setting it to now-24 hours at the least. - http://www.joeware.net (download joeware) http://www.cafeshops.com/joewarenet (wear joeware) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman Sent: Saturday, March 27, 2004 3:29 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] permissions to only disable an AD user account While I (personally, speaking in a position of no power over this) tend to agree that userAccountControl should be many attributes (IMHO anyway for Joe's reason as well as others not cited in this thread), the concept of having it as a constructed attribute (I assume that's what you mean when you say a "generated attribute"?) wouldn't be elegant here. Reason is, interop going forward will put you between a rock and a hard place. You'll drop yourself in to one of two scenarios: 1) You have two dsa's (say w2k and w2k03 rtm) that show a different userAccountControl for the same user. Reason is that the w2k03 rtm dsa knows of some additional logic for userAccountControl that reads ms-DS-NewAttributeInW2K03RTM and takes that in to account whereas w2k knows nothing of it. 2) It is functional level dependent on the construction logic which is too bad. I don't like the idea of userAccountControl on CN=SomeUser being 123 until you change functional level when it changes to 456. That'll drive people batty. Also, you can get current time on the DSA off of RootDSE if you want to set it to "now" from the perspective of the DC. Finally, if you fire up ADAM you'll find that on ADAM users we have a new attribute msDS-UserAccountDisabled (among others too.msds-UserDontExpirePassword, msDS-UserAccountAutoLocked, etc.). We're getting there.. ~Eric -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Saturday, March 27, 2004 1:32 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] permissions to only disable an AD user account Cute solution to an MS Generated issue. Yes, MS, you shouldn't have put everything into useraccountcontrol attribute like that... That should have been a generated attribute (or something else if you still needed it there) I think and the real info stuffed into other locations so it could be delegated properly... Now we have to ask for bit-level delegation capability which, I doubt, will ever happen... Alternatively I guess we could ask for some ldap "method type" attributes on objects that you set and they in the background pop the appropriate bits on the objects. Say have an attribute called something like userAccountControlDisable and when that is set to 1 it sets the appropriate BIT and when it is set to 0 clears the BIT. Think about the methods to move FSMO
RE: [ActiveDir] permissions to only disable an AD user account
You "actually" agree? Yee of little faith! :) The hotfix and schema update thing you toss in would need to be forest-wide (of course schema is implicitly, but fix would need to be as well) as userAccountControl is part of the PAS. It is, IMHO, not a solution to this problem. Say we need to get rid of this attribute, sure, but making it constructed isn't the way. True, 24 hours back is safer, but if you're making the change on a single dc if you bind to that dc and look at the time on it on RootDSE I would think you are safe. I'd need to think about that a bit more though, never thought about all of the caveats here. ~Eric -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Saturday, March 27, 2004 8:47 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] permissions to only disable an AD user account Cool and I actually agree. The constructed causes all sorts of issues, breaks all sorts of legacy code, especially anything that would search. So doing the additional method type attribs that would update useraccountcontrol on the user's behalf should be something that could work though obviously it wouldn't be something you could all of a sudden do on a current DC (2K or K3) without a handy dandy hotfix and schema update. One note on the "now" perspective with the DC... That would be now in one TZ. May be 10 hours off for another. I would still recommend setting it to now-24 hours at the least. - http://www.joeware.net (download joeware) http://www.cafeshops.com/joewarenet (wear joeware) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman Sent: Saturday, March 27, 2004 3:29 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] permissions to only disable an AD user account While I (personally, speaking in a position of no power over this) tend to agree that userAccountControl should be many attributes (IMHO anyway for Joe's reason as well as others not cited in this thread), the concept of having it as a constructed attribute (I assume that's what you mean when you say a "generated attribute"?) wouldn't be elegant here. Reason is, interop going forward will put you between a rock and a hard place. You'll drop yourself in to one of two scenarios: 1) You have two dsa's (say w2k and w2k03 rtm) that show a different userAccountControl for the same user. Reason is that the w2k03 rtm dsa knows of some additional logic for userAccountControl that reads ms-DS-NewAttributeInW2K03RTM and takes that in to account whereas w2k knows nothing of it. 2) It is functional level dependent on the construction logic which is too bad. I don't like the idea of userAccountControl on CN=SomeUser being 123 until you change functional level when it changes to 456. That'll drive people batty. Also, you can get current time on the DSA off of RootDSE if you want to set it to "now" from the perspective of the DC. Finally, if you fire up ADAM you'll find that on ADAM users we have a new attribute msDS-UserAccountDisabled (among others too.msds-UserDontExpirePassword, msDS-UserAccountAutoLocked, etc.). We're getting there.. ~Eric -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Saturday, March 27, 2004 1:32 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] permissions to only disable an AD user account Cute solution to an MS Generated issue. Yes, MS, you shouldn't have put everything into useraccountcontrol attribute like that... That should have been a generated attribute (or something else if you still needed it there) I think and the real info stuffed into other locations so it could be delegated properly... Now we have to ask for bit-level delegation capability which, I doubt, will ever happen... Alternatively I guess we could ask for some ldap "method type" attributes on objects that you set and they in the background pop the appropriate bits on the objects. Say have an attribute called something like userAccountControlDisable and when that is set to 1 it sets the appropriate BIT and when it is set to 0 clears the BIT. Think about the methods to move FSMO roles as to where I am going with that suggestion. Anyway, yes, this method should work. Note that just like when you disable an account it will take until expiration of the kerberos certs for it to actually do anything... I.E. If I have a cert to Server A and you disable or expire me my cert is STILL good until it expires and has to be renewed... By default those certs last 600 minutes aka 10 hours (too long IMO). If you are one of those folks who modified cert expiration times by extending them to crutch UNIX/LINUX kerberos clients who aren't doing cert renewal as nicely as MS was able to work out well then you have what I like to call... A security issue.
RE: [ActiveDir] permissions to only disable an AD user account
Cool and I actually agree. The constructed causes all sorts of issues, breaks all sorts of legacy code, especially anything that would search. So doing the additional method type attribs that would update useraccountcontrol on the user's behalf should be something that could work though obviously it wouldn't be something you could all of a sudden do on a current DC (2K or K3) without a handy dandy hotfix and schema update. One note on the "now" perspective with the DC... That would be now in one TZ. May be 10 hours off for another. I would still recommend setting it to now-24 hours at the least. - http://www.joeware.net (download joeware) http://www.cafeshops.com/joewarenet (wear joeware) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman Sent: Saturday, March 27, 2004 3:29 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] permissions to only disable an AD user account While I (personally, speaking in a position of no power over this) tend to agree that userAccountControl should be many attributes (IMHO anyway for Joe's reason as well as others not cited in this thread), the concept of having it as a constructed attribute (I assume that's what you mean when you say a "generated attribute"?) wouldn't be elegant here. Reason is, interop going forward will put you between a rock and a hard place. You'll drop yourself in to one of two scenarios: 1) You have two dsa's (say w2k and w2k03 rtm) that show a different userAccountControl for the same user. Reason is that the w2k03 rtm dsa knows of some additional logic for userAccountControl that reads ms-DS-NewAttributeInW2K03RTM and takes that in to account whereas w2k knows nothing of it. 2) It is functional level dependent on the construction logic which is too bad. I don't like the idea of userAccountControl on CN=SomeUser being 123 until you change functional level when it changes to 456. That'll drive people batty. Also, you can get current time on the DSA off of RootDSE if you want to set it to "now" from the perspective of the DC. Finally, if you fire up ADAM you'll find that on ADAM users we have a new attribute msDS-UserAccountDisabled (among others too.msds-UserDontExpirePassword, msDS-UserAccountAutoLocked, etc.). We're getting there.. ~Eric -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Saturday, March 27, 2004 1:32 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] permissions to only disable an AD user account Cute solution to an MS Generated issue. Yes, MS, you shouldn't have put everything into useraccountcontrol attribute like that... That should have been a generated attribute (or something else if you still needed it there) I think and the real info stuffed into other locations so it could be delegated properly... Now we have to ask for bit-level delegation capability which, I doubt, will ever happen... Alternatively I guess we could ask for some ldap "method type" attributes on objects that you set and they in the background pop the appropriate bits on the objects. Say have an attribute called something like userAccountControlDisable and when that is set to 1 it sets the appropriate BIT and when it is set to 0 clears the BIT. Think about the methods to move FSMO roles as to where I am going with that suggestion. Anyway, yes, this method should work. Note that just like when you disable an account it will take until expiration of the kerberos certs for it to actually do anything... I.E. If I have a cert to Server A and you disable or expire me my cert is STILL good until it expires and has to be renewed... By default those certs last 600 minutes aka 10 hours (too long IMO). If you are one of those folks who modified cert expiration times by extending them to crutch UNIX/LINUX kerberos clients who aren't doing cert renewal as nicely as MS was able to work out well then you have what I like to call... A security issue. Now specifically, I haven't tested it either, but I don't think this script will work with a delegated ID. It is using the WinNT provider which knows less about delegation than the Exchange Dev guys. Almost everything doing any anything in the WinNT provider falls back to some NET API call and they almost without exception all require some level of builtin permissions to do changes... Like Account Op, Sever Op, Admin, etc. Recommendation would be to try and change it to the LDAP provider to see if that works. I would say set the date to some time in the past, say 24 hours ago or something like that then you don't have an TZ worries that could come up with setting the exact current time. joe - http://www.joeware.net (download joeware) http://www.cafeshops.com/joewarenet (wear joeware) -Original Message- From: [EMAIL PROTECTED] [m
RE: [ActiveDir] permissions to only disable an AD user account
While I (personally, speaking in a position of no power over this) tend
to agree that userAccountControl should be many attributes (IMHO anyway
for Joe's reason as well as others not cited in this thread), the
concept of having it as a constructed attribute (I assume that's what
you mean when you say a "generated attribute"?) wouldn't be elegant
here. Reason is, interop going forward will put you between a rock and a
hard place. You'll drop yourself in to one of two scenarios:
1) You have two dsa's (say w2k and w2k03 rtm) that show a different
userAccountControl for the same user. Reason is that the w2k03 rtm dsa
knows of some additional logic for userAccountControl that reads
ms-DS-NewAttributeInW2K03RTM and takes that in to account whereas w2k
knows nothing of it.
2) It is functional level dependent on the construction logic which is
too bad. I don't like the idea of userAccountControl on CN=SomeUser
being 123 until you change functional level when it changes to 456.
That'll drive people batty.
Also, you can get current time on the DSA off of RootDSE if you want to
set it to "now" from the perspective of the DC.
Finally, if you fire up ADAM you'll find that on ADAM users we have a
new attribute msDS-UserAccountDisabled (among others
too.msds-UserDontExpirePassword, msDS-UserAccountAutoLocked, etc.).
We're getting there..
~Eric
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of joe
Sent: Saturday, March 27, 2004 1:32 PM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] permissions to only disable an AD user account
Cute solution to an MS Generated issue. Yes, MS, you shouldn't have put
everything into useraccountcontrol attribute like that... That should
have
been a generated attribute (or something else if you still needed it
there)
I think and the real info stuffed into other locations so it could be
delegated properly... Now we have to ask for bit-level delegation
capability
which, I doubt, will ever happen... Alternatively I guess we could ask
for
some ldap "method type" attributes on objects that you set and they in
the
background pop the appropriate bits on the objects. Say have an
attribute
called something like userAccountControlDisable and when that is set to
1 it
sets the appropriate BIT and when it is set to 0 clears the BIT. Think
about
the methods to move FSMO roles as to where I am going with that
suggestion.
Anyway, yes, this method should work. Note that just like when you
disable
an account it will take until expiration of the kerberos certs for it to
actually do anything... I.E. If I have a cert to Server A and you
disable or
expire me my cert is STILL good until it expires and has to be
renewed... By
default those certs last 600 minutes aka 10 hours (too long IMO). If you
are
one of those folks who modified cert expiration times by extending them
to
crutch UNIX/LINUX kerberos clients who aren't doing cert renewal as
nicely
as MS was able to work out well then you have what I like to call... A
security issue.
Now specifically, I haven't tested it either, but I don't think this
script
will work with a delegated ID. It is using the WinNT provider which
knows
less about delegation than the Exchange Dev guys. Almost everything
doing
any anything in the WinNT provider falls back to some NET API call and
they
almost without exception all require some level of builtin permissions
to do
changes... Like Account Op, Sever Op, Admin, etc.
Recommendation would be to try and change it to the LDAP provider to see
if
that works. I would say set the date to some time in the past, say 24
hours
ago or something like that then you don't have an TZ worries that could
come
up with setting the exact current time.
joe
-
http://www.joeware.net (download joeware)
http://www.cafeshops.com/joewarenet (wear joeware)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan
Sent: Saturday, March 27, 2004 12:29 PM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] permissions to only disable an AD user account
Mike,
I haven't tested this out, but I suppose that one could do as you
suggest
and run a script similar to the following:
Dim User
Dim UserName
Dim UserDomain
Dim AccountExpirationDate
UserDomain = "Target_User_Domain"
UserName = "Target_User_Name"
Set User = GetObject("WinNT://" & UserDomain & "/" & UserName & ",user")
AccountExpirationDate = #Date on which to expire [today / yesterday?]#
'format is #mm/dd/# - at least for us US folks
User.AccountExpirationDate = AccountExpirationDate User.SetInfo
Rick Kingslan MCSE, MCSA, MCT, CISSP
Microsoft MVP:
Windows Server / Directory Services
Windows Server / Rights Management
Associate Expert
Expert Zone - www.microsoft.com/windowsxp/expertzone
WebLog - www.msm
RE: [ActiveDir] permissions to only disable an AD user account
Cute solution to an MS Generated issue. Yes, MS, you shouldn't have put
everything into useraccountcontrol attribute like that... That should have
been a generated attribute (or something else if you still needed it there)
I think and the real info stuffed into other locations so it could be
delegated properly... Now we have to ask for bit-level delegation capability
which, I doubt, will ever happen... Alternatively I guess we could ask for
some ldap "method type" attributes on objects that you set and they in the
background pop the appropriate bits on the objects. Say have an attribute
called something like userAccountControlDisable and when that is set to 1 it
sets the appropriate BIT and when it is set to 0 clears the BIT. Think about
the methods to move FSMO roles as to where I am going with that suggestion.
Anyway, yes, this method should work. Note that just like when you disable
an account it will take until expiration of the kerberos certs for it to
actually do anything... I.E. If I have a cert to Server A and you disable or
expire me my cert is STILL good until it expires and has to be renewed... By
default those certs last 600 minutes aka 10 hours (too long IMO). If you are
one of those folks who modified cert expiration times by extending them to
crutch UNIX/LINUX kerberos clients who aren't doing cert renewal as nicely
as MS was able to work out well then you have what I like to call... A
security issue.
Now specifically, I haven't tested it either, but I don't think this script
will work with a delegated ID. It is using the WinNT provider which knows
less about delegation than the Exchange Dev guys. Almost everything doing
any anything in the WinNT provider falls back to some NET API call and they
almost without exception all require some level of builtin permissions to do
changes... Like Account Op, Sever Op, Admin, etc.
Recommendation would be to try and change it to the LDAP provider to see if
that works. I would say set the date to some time in the past, say 24 hours
ago or something like that then you don't have an TZ worries that could come
up with setting the exact current time.
joe
-
http://www.joeware.net (download joeware)
http://www.cafeshops.com/joewarenet (wear joeware)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan
Sent: Saturday, March 27, 2004 12:29 PM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] permissions to only disable an AD user account
Mike,
I haven't tested this out, but I suppose that one could do as you suggest
and run a script similar to the following:
Dim User
Dim UserName
Dim UserDomain
Dim AccountExpirationDate
UserDomain = "Target_User_Domain"
UserName = "Target_User_Name"
Set User = GetObject("WinNT://" & UserDomain & "/" & UserName & ",user")
AccountExpirationDate = #Date on which to expire [today / yesterday?]#
'format is #mm/dd/# - at least for us US folks
User.AccountExpirationDate = AccountExpirationDate User.SetInfo
Rick Kingslan MCSE, MCSA, MCT, CISSP
Microsoft MVP:
Windows Server / Directory Services
Windows Server / Rights Management
Associate Expert
Expert Zone - www.microsoft.com/windowsxp/expertzone
WebLog - www.msmvps.com/willhack4food
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Thommes, Michael M.
Sent: Saturday, March 27, 2004 10:25 AM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] permissions to only disable an AD user account
Hi Rick,
Thanks for the feedback! That's exactly what I thought would happen but
I needed an expert's view! I was thinking instead I could achieve roughly
the same affect by giving the group read/write access over the User Account
propery named "AccountExpires" and set it to the current timestamp. Is this
thinking also flawed?
Mike Thommes
-Original Message-
From: Rick Kingslan [mailto:[EMAIL PROTECTED]
Sent: Sat 3/27/2004 10:06 AM
To: [EMAIL PROTECTED]
Cc:
Subject: RE: [ActiveDir] permissions to only disable an AD user
account
Mike,
The property that you're looking to delegate is the 'Write
userAccountControl'. However, that does open up an interesting can of
worms. The userAccountControl proerty, as you may well know, is a series of
flags that control a number of aspects of the user account - enable (flag
value 512) and disable (flag value 514) being only two. Look here for more
info.
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q305144
So, if you delegate the ability to disable an account, you're also
going to, by association, delegate quite a bit more - which you may not want
to do, which means it really can't be done - directly. You of course, can
RE: [ActiveDir] permissions to only disable an AD user account
Mike,
I haven't tested this out, but I suppose that one could do as you suggest
and run a script similar to the following:
Dim User
Dim UserName
Dim UserDomain
Dim AccountExpirationDate
UserDomain = "Target_User_Domain"
UserName = "Target_User_Name"
Set User = GetObject("WinNT://" & UserDomain & "/" & UserName & ",user")
AccountExpirationDate = #Date on which to expire [today / yesterday?]#
'format is #mm/dd/# - at least for us US folks
User.AccountExpirationDate = AccountExpirationDate
User.SetInfo
Rick Kingslan MCSE, MCSA, MCT, CISSP
Microsoft MVP:
Windows Server / Directory Services
Windows Server / Rights Management
Associate Expert
Expert Zone - www.microsoft.com/windowsxp/expertzone
WebLog - www.msmvps.com/willhack4food
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Thommes, Michael M.
Sent: Saturday, March 27, 2004 10:25 AM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] permissions to only disable an AD user account
Hi Rick,
Thanks for the feedback! That's exactly what I thought would happen but
I needed an expert's view! I was thinking instead I could achieve roughly
the same affect by giving the group read/write access over the User Account
propery named "AccountExpires" and set it to the current timestamp. Is this
thinking also flawed?
Mike Thommes
-Original Message-
From: Rick Kingslan [mailto:[EMAIL PROTECTED]
Sent: Sat 3/27/2004 10:06 AM
To: [EMAIL PROTECTED]
Cc:
Subject: RE: [ActiveDir] permissions to only disable an AD user
account
Mike,
The property that you're looking to delegate is the 'Write
userAccountControl'. However, that does open up an interesting can of
worms. The userAccountControl proerty, as you may well know, is a series of
flags that control a number of aspects of the user account - enable (flag
value 512) and disable (flag value 514) being only two. Look here for more
info.
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q305144
So, if you delegate the ability to disable an account, you're also
going to, by association, delegate quite a bit more - which you may not want
to do, which means it really can't be done - directly. You of course, can
script or provide a compiled tool called, e.g. 'accountdisable.exe' which
would do nothing more. But, the risk is that the property is well
documented and someone with half a brain could figure out that they have
more than what was intended. They then will be able to create their own
scripts and have a good old time playing with the properties of the users in
their delegated area.
Hope this answers what you are looking for.
Rick Kingslan MCSE, MCSA, MCT, CISSP
Microsoft MVP:
Windows Server / Directory Services
Windows Server / Rights Management
Associate Expert
Expert Zone - www.microsoft.com/windowsxp/expertzone
WebLog - www.msmvps.com/willhack4food
_
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Thommes, Michael M.
Sent: Friday, March 26, 2004 4:00 PM
To: Active Directory Mailing List (E-mail)
Subject: [ActiveDir] permissions to only disable an AD user account
I hope there is an easy answer to the following question: I would
like to delegate authority to a group to be able to disable user accounts
down in an OU. But I don't want to have to also give them the ability to
create/delete user accounts. I've looked around the Delegation Wizard
custom tasks, but really don't find anything to do this single purpose
action. Anybody have an answer? Thanks!
Mike Thommes
List info : http://www.activedir.org/mail_list.htm
List FAQ: http://www.activedir.org/list_faq.htm
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
List info : http://www.activedir.org/mail_list.htm
List FAQ: http://www.activedir.org/list_faq.htm
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] permissions to only disable an AD user account
Hi Rick,
Thanks for the feedback! That's exactly what I thought would happen but I needed
an expert's view! I was thinking instead I could achieve roughly the same affect by
giving the group read/write access over the User Account propery named
"AccountExpires" and set it to the current timestamp. Is this thinking also flawed?
Mike Thommes
-Original Message-
From: Rick Kingslan [mailto:[EMAIL PROTECTED]
Sent: Sat 3/27/2004 10:06 AM
To: [EMAIL PROTECTED]
Cc:
Subject: RE: [ActiveDir] permissions to only disable an AD user account
Mike,
The property that you're looking to delegate is the 'Write
userAccountControl'. However, that does open up an interesting can of worms. The
userAccountControl proerty, as you may well know, is a series of flags that control a
number of aspects of the user account - enable (flag value 512) and disable (flag
value 514) being only two. Look here for more info.
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q305144
So, if you delegate the ability to disable an account, you're also going to,
by association, delegate quite a bit more - which you may not want to do, which means
it really can't be done - directly. You of course, can script or provide a compiled
tool called, e.g. 'accountdisable.exe' which would do nothing more. But, the risk is
that the property is well documented and someone with half a brain could figure out
that they have more than what was intended. They then will be able to create their
own scripts and have a good old time playing with the properties of the users in their
delegated area.
Hope this answers what you are looking for.
Rick Kingslan MCSE, MCSA, MCT, CISSP
Microsoft MVP:
Windows Server / Directory Services
Windows Server / Rights Management
Associate Expert
Expert Zone - www.microsoft.com/windowsxp/expertzone
WebLog - www.msmvps.com/willhack4food
_
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thommes,
Michael M.
Sent: Friday, March 26, 2004 4:00 PM
To: Active Directory Mailing List (E-mail)
Subject: [ActiveDir] permissions to only disable an AD user account
I hope there is an easy answer to the following question: I would like to
delegate authority to a group to be able to disable user accounts down in an OU. But
I don't want to have to also give them the ability to create/delete user accounts.
I've looked around the Delegation Wizard custom tasks, but really don't find anything
to do this single purpose action. Anybody have an answer? Thanks!
Mike Thommes
List info : http://www.activedir.org/mail_list.htm
List FAQ: http://www.activedir.org/list_faq.htm
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] permissions to only disable an AD user account
Mike, The property that you're looking to delegate is the 'Write userAccountControl'. However, that does open up an interesting can of worms. The userAccountControl proerty, as you may well know, is a series of flags that control a number of aspects of the user account - enable (flag value 512) and disable (flag value 514) being only two. Look here for more info. http://support.microsoft.com/default.aspx?scid=kb;en-us;Q305144 So, if you delegate the ability to disable an account, you're also going to, by association, delegate quite a bit more - which you may not want to do, which means it really can't be done - directly. You of course, can script or provide a compiled tool called, e.g. 'accountdisable.exe' which would do nothing more. But, the risk is that the property is well documented and someone with half a brain could figure out that they have more than what was intended. They then will be able to create their own scripts and have a good old time playing with the properties of the users in their delegated area. Hope this answers what you are looking for. Rick Kingslan MCSE, MCSA, MCT, CISSPMicrosoft MVP:Windows Server / Directory ServicesWindows Server / Rights ManagementAssociate ExpertExpert Zone - www.microsoft.com/windowsxp/expertzoneWebLog - www.msmvps.com/willhack4food From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thommes, Michael M.Sent: Friday, March 26, 2004 4:00 PMTo: Active Directory Mailing List (E-mail)Subject: [ActiveDir] permissions to only disable an AD user account I hope there is an easy answer to the following question: I would like to delegate authority to a group to be able to disable user accounts down in an OU. But I don't want to have to also give them the ability to create/delete user accounts. I've looked around the Delegation Wizard custom tasks, but really don't find anything to do this single purpose action. Anybody have an answer? Thanks! Mike Thommes
