Re: Wierd permissions on user accounts

There's a defaultSecurityDescriptor defined in AD schema, it is stamped on
objects that are created without specific SDs. Clicking "Default" button
reapplies it to an existing object. It has no idea what the original SD was
at the time of object creation.

That said, as I mentioned earlier, your permissions are bad. With these
DENYs, *nobody* will be able to change password on the account.

--
Dmitri Gavrilov
SDE, Active Directory Core

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"troy240sx@xxxxxxxxx" <troy240sxyahoocom@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message news:09DA159C-E18B-4D58-8F85-12060FAFAA4F@xxxxxxxxxxxxxxxx
>
> That is exactly what I tought would happen. These DENY rules are assigned
> to user accounts when I created them...by default. When I create a new
> account and look at the permissions. I have the following deny rules..
>
> DENY - Everyone - Change Password - <not inherited> - This object only
> DENY - Self - Change Password - <not inherited> - This object only
>
> If I click the DEFAULT button in the Advance security settings on this NEW
> user account I just created, these Deny rules are removed.
>
> Why are the default permissions that are assigned to the object different
> then the permissions assigned to the object after using the Default
> button?
>
> "Dmitri Gavrilov [MSFT]" wrote:
>
>> If you put in DENY EVERYONE change password, then nobody will ever be
>> able
>> to change the pwd, because a DENY ace has precedence over any ALLOW ace.
>>
>> Note that ALLOW EVERYONE change password only means that anybody who
>> knows
>> the old password, can change it to the new value. Change password
>> operation
>> is defined as "remove old value" + "add new value", and the old value
>> must
>> match. This is different from reset pwd, where you just specify the new
>> value.
>>
>> --
>> Dmitri Gavrilov
>> SDE, Active Directory Core
>>
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>> Use of included script samples are subject to the terms specified at
>> http://www.microsoft.com/info/cpyright.htm
>>
>> "troy240sx@xxxxxxxxx" <troy240sxyahoocom@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote
>> in
>> message news:B678EA79-C64B-4592-B3AA-212A51F8E54B@xxxxxxxxxxxxxxxx
>> >
>> > That makes sense but why are the permissions different between a newly
>> > created account and the permissions on that same account after using
>> > the
>> > Default button? Wouldn't the default permissions be the permissions
>> > that
>> > were assigned to it by default (upon creation)?
>> >
>> > On account created in AD, by default, it has DENY EVERYONE and SELF
>> > CHANGE
>> > PASSWORD. After you click the default button these are removed.
>> >
>> > According to Q258788 (which is for 2000 not 2003) users would not be
>> > able
>> > to
>> > change their password without being logged on. Since DENY EVERYONE and
>> > SELF
>> > CHANGE PASSWORD is the default for an account created in AD, I can
>> > expect
>> > to
>> > see this problem on new accounts created in AD (not migrated) because a
>> > DENY
>> > on the user will always be the effective permission, right? If this is
>> > true,
>> > your saying that everyone account that is created in AD does not have
>> > the
>> > correct permissions assigned to it and needs to be change when the
>> > account
>> > is
>> > created?
>> >
>> > Am I understanding this correctly? Is this going to be fix in a hotfix
>> > or
>> > service pack?
>> >
>> > "Chriss3 [MVP]" wrote:
>> >
>> >> Hello.
>> >> This is a know issue, you havening the behavior of KB258788.
>> >> http://support.microsoft.com/kb/258788/EN-US/
>> >>
>> >> --
>> >> Regards
>> >> Christoffer Andersson
>> >> Microsoft MVP - Directory Services
>> >>
>> >> No email replies please - reply in the newsgroup
>> >> ------------------------------------------------
>> >> http://www.chrisse.se - Active Directory Tips
>> >>
>> >> "troy240sx@xxxxxxxxx" <troy240sxyahoocom@xxxxxxxxxxxxxxxxxxxxxxxxx>
>> >> skrev
>> >> i
>> >> meddelandet news:1EC95DCD-3BFB-4E32-AC9E-8D175ACACBA0@xxxxxxxxxxxxxxxx
>> >> >
>> >> >
>> >> > We are migrating from NT 4.0 to 2003 AD. We are using the ADMTv.2
>> >> > tool
>> >> > to
>> >> > migrate computer and user accounts. While migrating accounts I have
>> >> > noticed
>> >> > that there are different permissions applied to accounts that have
>> >> > been
>> >> > migrated and accounts created in AD. After further investigation I
>> >> > also
>> >> > noticed that if you create a account in the 2003 environment and
>> >> > user
>> >> > dsacls
>> >> > to dump the permissions to a text file. Then on that same user
>> >> > account
>> >> > go
>> >> > into the advanced security properties, click the Default button
>> >> > (which
>> >> > is
>> >> > suppose to replace the permissions with the default settings). Now
>> >> > use
>> >> > dsacls to dump the new permissions to a different text file. Use FC
>> >> > to
>> >> > do
>> >> > a
>> >> > file compare and the permissions are different.
>> >> >
>> >> > Why are the permissions different between a migrated account and a
>> >> > AD
>> >> > created account?
>> >> >
>> >> > Why are the permissions changed when you click the default button if
>> >> > you
>> >> > haven't change the default permissions when you created the account?
>> >> >
>> >> > What concerns me the most is that it changes the DENY EVERYONE
>> >> > CHANGE
>> >> > PASSWORD permission to ALLOW EVERYONE CHANGE PASSWORD permission. I
>> >> > have
>> >> > logged into our domain with a Domain User account <no special
>> >> > rights/permissions> and this user was NOT able to change the
>> >> > password.
>> >> > The
>> >> > permissions seem to be misleading.
>> >> >
>> >> > The default button changes the following permissions.
>> >> > DENY - EVERYONE - CHANGE PASSWORD ---> REMOVED
>> >> > DENY - NT AUTHORITY\SELF - CHANGE PASSWORD ---> REMOVED
>> >> >
>> >> > C:>fc before.txt after.txt
>> >> > Comparing files BEFORE.txt and AFTER.TXT
>> >> > ***** BEFORE.txt
>> >> > READ PROPERTY
>> >> > Deny Everyone Change Password
>> >> > Deny NT AUTHORITY\SELF Change Password
>> >> > Allow Everyone Change Password
>> >> > ***** AFTER.TXT
>> >> > READ PROPERTY
>> >> > Allow Everyone Change Password
>> >> > *****
>> >> >
>> >> > Can someone confirm that this is normal? If possible I would also
>> >> > like
>> >> > a
>> >> > explanation why it works like this.
>> >> >
>> >> > NOTE: I didn't change any of the permissions up the structure of
>> >> > where
>> >> > this
>> >> > user account is....
>> >>
>> >>
>> >>
>>
>>
>>


.