Link to home
Start Free TrialLog in
Avatar of callit
callitFlag for United States of America

asked on

Deny read access for all properties in active directory

I'm using a piece of software that checks the entire AD for expiring user accounts.  The software runs as a service, and with a user account set up just for this purpose.  I am trying to limit which accounts the software checks by denying read access on certain OUs.

I have tried to deny the SWService user account read access to the Active Directory in every area I can think of, but certain read permissions persist.

The software is running on a domain controller.  The user account is a member of Domain Users and Administrators (builtin).  If I remove the user from administrators, the service will not start.  I'm not sure if membership in administrators is causing this or not.

The server that the software is running on is Windows Server 2008.  The domain is at Windows 2003 functional level.

adpermissiondeny.JPG
active-directory-effective.JPG
ASKER CERTIFIED SOLUTION
Avatar of Mike Kline
Mike Kline
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of callit

ASKER

After performing my own research, I'm coming to the same conclusion.  It looks like the only way to accomplish what I'm trying to do would be to change the schema or change the permission on every user account.

Here's the article I found:

http://www.usercube.com/blog/lock-down-active-directory-account

From the article:

"When someone connects to Active Directory to perform an operation, it reads the ACL of the targeted entries and processes the ACE is the following order:

Deny on current entry,
Allow on current entry,
Deny from parent entries,
Allow from parent entries."

This is contrary to what I thought I knew about permissions.  I thought denies were always evaluated first.
Avatar of callit

ASKER

Also, the software doesn't need admin rights to read from the directory.  The manufacturer suggested I make it a domain user.  They do claim the software needs admin rights on the local box however.  It was my decision to install it directly on the DC.
Avatar of callit

ASKER

I've followed up on this a bit - here's what I've found:

I moved the software to a member server.  I deleted and recreated the account for good measure.  I made the account a member of domain users.  I made the account a member of Administrators (local) on the member server.

I set the deny list contents, deny read all properties, and deny read permissions on the OUs that I do not want the service to see.  I logged in as the service user account, and was able to verify that it could not see the OUs in question.  

This may have been an issue with installing the software on the DC itself, or the account being a member of the DC builtin administrators group.
good work and thanks for the updated info,  I'm with you...don't usually install software on the DC.