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 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/yyyy# - 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/ 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/ 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/
