[lukeandmax]

Hello Everyone (actually I should have said "Hello Authenticated Users!")

As promised, here we are with our latest discover. The reason why we expected so much before posting this message is because we wanted to do more tests.
I really don't know where to start from. Let say that some weeks ago we were talking about security in Active Directory DACLS, and we made some considerations about delegating administration of user accounts in OUs. Background: we are very, veeeery paranoid regarding security

We made up with a particular issue: for example, when you need to delegate administration of user account contained "Business Users" OU and all sub OUs, dacls must be modified in order to allow Creation and Deletion of User User Objects + Full Control over User Objects, that is the standard permissions added by Delegation Wizards.
Well the question is .... what if Exchange is present on the Enterprise? (we are talking about 1 forest with empty root domain + 19 child domains, with very large helpdesk center).
If Exchange is present and, for example, I delegate user account administration to "Helpdesk Users Dept", every member of this group will get Full Control over User Objects contained in "Business Users"; Full Control also includes SEND AS permission, which may not be feasible for my organization. So we thought: why don't we remove Send As permission by denying explicitely?...... been there, done that.

Wait a moment! Let us think.... Even if I have been denied Send As Permission, I am member still of "Helpdesk Users Dept" so I have FC, that includes "Modify Permissions", so I can change it again and remove Send As Denial.
Well here we are once again: let's explicitely deny Modify Permissions on User Objects to "Helpdesk Users Dept".

After this, we want to verify these new permissions work. So we logged on XP workstation with user account member of "Helpdesk Users Dept", opened ADUC, clicked on Business Users OU, created a user account, then rightclick on user account/properties/security/advanced in order to view user's DACLS, and.....

LSASS Crashed on DC! Deadlock condition and reboot DC in 30 seconds (error code -1073741819)

We reproduced the problem in another domain and ....

LSASS Crashed again!!!!

Also, another try: creation of user account, go ahead during creation and used a non-compliant 5 chars, password (domain sets min 12 chars), go ahead, received message that password is not compliant and....
LSASS Crashed again!!! (that's because the user was created but not confirmed, so it tried to delete the user object!, in fact after reboot the user account was still there but disabled )

So guys... have fun

Luke & Max

PS: it seems that SP1 patched this bug. I've tried it right now and it does not crash.

[guyt]

Great work guys !

2 immediate comments before I run home to test it:

1) Instead of giving FC, I would delegate Write Property on the attributes the HD need to administer. I never liked explicit denies when doing delegations.

2) PM/MSN me. It could be that I've had a revelation about your previus thread

[guyt]

Confirmed on W2K3 (no SP1) + E2K3 (no SP)

[wkasdo]

hahahaaa! Good one! Confirmed, boys! Just had a nice crash! That's a very nice DOS for non admins. I know quite a few networks where a delegated admin could do this.

Daniel, you might want to hide this thread as a public service

W2003 RTM, Exchange 2003 RTM, single domain.

[wkasdo]

Found it. Fixed in SP1

http://support.microsoft.com/kb/818080/

This problem may occur when an inheritable Deny access control entry (ACE) is applied to an organizational unit (OU) that inherits only to user objects but applies to all properties. The access violation occurs when a principal that this Deny ACE applies to queries users in the OU.

[lukeandmax]

Hi there

Let's start with some comments

1) Guyt is right, it's a good practice delegating only write properties but this way, the delegation work becomes tedious, and you loose all AD potential.

2) Guyt, ASAP we're gonna pm you, as you can see we changed our nick; last topics were written only by one of us, now are writing toghether, so we use a common account (if you wan you can write us, our email address is public)...we're very curious!!!!

3) We noticed that SP1 resolved this, we just have not tested this on w2000

4) The real problem stands still. FC delegated to HD dept is too dangerous if Exchange is present on the Enterprise!

[danielp]

Great thread guys! Well worth reading!

[lukeandmax]

Luke suggests if it is possible to rename the topic to "A good reason to upgrad your servers to SP1", in order to avoid some stupid people to damage their DCs..... well... I think it may be a good idea...
Of course our post was not intended for stupid admins who means to make damages, I think you understand

Is it possible?

[lukeandmax]

Hi all,
just another point about delegating. In the test we did we used the default "Create, delete and manage user accounts" in the Delegation Wizard.. This settings enable the delegated user/group to create user inside the OU but also grant FC an all user objects..
This could be OK if your organization doesn't use Exchange, since the delegated user/group has the Send AS permission on all user objects.

Users need to trust their administrators but there are many organization where this could not be applied.. Moreover, users have no way to protect themselves againist a bad administrator.. So next time we will talk about security, we should say "administrator is God, can do whatever he/she wants and no one can block him/her": the real owner any company is the IT Admin!

Have a nice day

[guyt]

I think we need to separate this to sub-topics:

1) To my understanding the crash of LSASS has nothing to do with Exchange (as outlined in the KB wkasdo has pointed to). The cause is the conflict between the user right of helpdesk to do anything with the object (as they are the owners of the object) and the Deny ACE in the DACL.

2) As for Exchange and SendAs and rest of the permissions, what I would do is:
a. Proxy the creation of user accounts via an external process that does not make the helpdesk staff the owners of the user objects

b. Delegate only the required attribute sets to the helpdesk without granting them FC (I do not like the approach of giving too much and then denying).

c. Not allow deletion of user objects to Helpdesk (I would let them only only disable the accounts) and proxy the deletion via the same external process (can be easily done via web). This will give you the level of control that prevents most of accidental deletions and f#$k ups...

The main point is that allowing helpdesk to create user accounts (and thus becoming the object owners) requires too many permissions that they do not need for anything else and opens up potential security holes they can exploit or just use incorrectly.

As for the owners of the company, let me tell you a short story...

I am a bit of Linux enthusiast and sometimes participate in instaparties the Linux folks set up in the nearest university - basically people come with their computers and we help them install Linux, answer questions and give them enough info to get up and running...
The event is organized by folks from university, and those academic rats have no clue about how things work in real life...

So a ear ago, me and a friend of mine were the ones to setup the infrastructure, created the network installations and setup the hardware (partially our own, partially borrowed for the event).
During the event, the academy folks started to argue with us about how to run the gig (academy people always have those fascinating theories). After letting my friend argue with them for 10 minutes and seeing that it does not lead anywhere, I walked to the server that was used for network installs (you can compare it to RIS, if you want) and just pulled the electricity plug (well, this was MY server ).
The argument was instantly settled. Now they knew who holds the plug and things got back to the track

The point ? as long as someone can pull your plug, you do not really own the show