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




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

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/

Reply via email to