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:

DC01.production.local 172.16.10.10
DC02.production.local 172.16.10.11

DC01.test.local 172.16.20.10

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.
dfollisAsked:
Who is Participating?
 
Netman66Commented:
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.

0
 
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.
0
 
Netman66Commented:
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.
0
How do you know if your security is working?

Protecting your business doesn’t have to mean sifting through endless alerts and notifications. With WatchGuard Total Security Suite, you can feel confident that your business is secure, meaning you can get back to the things that have been sitting on your to-do list.

 
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.
0
 
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.
0
 
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.
0
 
Netman66Commented:
Ok, understood.  I'll think on this.

0
 
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.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.