Domain Admin in test domain has full access to production domain shares???

I must be doing something stupid, but I can't figure this out.  Wondering if anyone else has seen this.

I have two independant domains.  One is production, and one I setup today to test Exchange 2010 deployment.  I will call them test.local and production.local

Both of them are running on Server 2008 R2 DCs.

Production is in 2003 mode
Test is in 2008 mode

They are running on different IP ranges, but with a /16 subnet so I can ping all hosts from each other.  They share a common gateway which is our firewall.

There is no type of forest trust or relationships setup.  DNS IPs are:



Both accounts use the same username for domain admin but with different passwords.

There is a file server on the production domain that has shares set to Everyone (Read,Change).  The files/folders then have ACLs set for the specific users/groups who need access (NTFS volumes of course).  Production\Administrators have FC for all of the shares.  This works as expected when a user from the production.local domain attempts to connect to a share they do not have access to, Access Denied.

Shockingly, when I attempted to connect to my fileserver.production.local machine from dc01.test.local, I was not prompted for a valid username and password from the production.local domain.  To my further horror I was able to browse any of the files on the server.  This doesn't make sense.  I'm assuming that simply setting up a test domain with an Admin user should not give one full access to any other domains on that segment.

Has anyone seen this before?  I've been a Windows Server admin for a long time and have always felt like I had a good command of Sharing and ACLs, but this has me scratching my head.
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

dfollisAuthor Commented:
After some more testing it appears part of the issue is I have at times been using "Authenticated Users" for the sharing portion of the permission.  It appears that is ANY user that has been authenticated by ANY OS and not necessarily by the domain.  This seems nuts.  What still doesn't make sense is that the ACLs are not taking precedence.  I have always been under the impression that file level ACLs were the final determinate if a file could be opened by a user or not.  As a result I often shared my folders with "Everyone" Read/Change Perms and then applied ACLs based on user or group needs.  Often SYSTEM and Administrators had FC ACLs on these files also.  Something isn't right.
This is normal should you be using Authenticated Users.  It's fine on the share, but not on the NTFS perms.  It's effectively like EVERYONE only a tad more secure....

I suspect this Admin account may be part of Enterprise Admins maybe?  If it's all the same Forest then you'll have to chase down the permissions this account has based on the Forest in order to find the inheritance issue.
dfollisAuthor Commented:
Domains are completely seperate and are not known to each other.  They have unique DCs and DNS servers.  That is what bothered me.  When I think of Authenticated Users I'm assuming that means authenticated by the domain.  That must be an incorrect assumption.
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

dfollisAuthor Commented:
Netman, what do you put on your shares, versus your NTFS ACLs?  I understand that is a "it depends" questions.  Looking for general rule.
I understand that domains are different, but did you install them into the same forest?

As a rule, I use Authenticated Users - Full control on the share (unless it's an Admin share) and NTFS permissions that include Administrators, SYSTEM - full control, Users - Read & Execute, traverse folders (parent folder), and subfolders have ACLs set based on either group membership and/or specific accounts as required.

You can also install Access-based enumeration which acts just like Novell's file system and hides all folders a user doen't have access to.  This removes any temptation to try to open them.


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
dfollisAuthor Commented:
No trust relationships exist.  test.local domain was setup independant of production.local and was created as a new Forest root with its own DC and DNS.
Ok, understood.  I'll think on this.

dfollisAuthor Commented:
I'm using Domain User in place of Everyone at the share level.  That seems to work.  It would be nice if there was a document that spelled out all of the rights that each one of these built-in users has.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
OS Security

From novice to tech pro — start learning today.