Link to home
Start Free TrialLog in
Avatar of monkfish72
monkfish72Flag for United Kingdom of Great Britain and Northern Ireland

asked on

Server 2012 RODC is caching all accounts - including administrator accounts

We have 3 Server 2012 RODC's - they are all caching all our AD accounts - including the administrator accounts.  In the resultant policy it says 'Deny Explicit' and 'Deny Implicit' but it is still caching the passwords and storing locally

I have disconnected from the network and tested access - Admin accounts can still login so it is not a false positive - it is just ignoring completely the password replication policy

We have a 2003 Forest and domain - and the RODC's are GC's but I cannot find anything to say this is a problem - Google brings back no hits - we seem to be alone with this issue - what am I doing wrong?
Avatar of Mahesh
Mahesh
Flag of India image

How you are testing? can you please elaborate

If your client alternate DNS (DC) is available and you disconnected RODC, client will pickup login from alternate DC server which may be in remote site. Just remove all alternate DNS servers from client network settings and then check

RODC will cache account password only if you allowed to do so, in fact if you added account / group under allowed password replication policy in the properties of RODC, if you added any group (like domain users) as allowed password replication, RODC will cache user logon info for all accounts in domain except admin accounts (high privileged accounts such as member of domain admins)

Also what about cached logon settings, have you configured cached logon settings to 0 for clients through GPO, so that if DC is not available client won't be able to logon, in that case it can logon only if RODC have cached his credentials (ensure that client cannot connect to other R/W DCs through alternate DNS), otherwise even if you disconnect RODC form network, client can logon through cached credentials which is default behavior
https://technet.microsoft.com/en-us/library/jj852209(v=ws.11).aspx

RODC should be used where remote connectivity is very less and you need kerberos ticket from local domain controller (RODC) even if your link is down (through cached credentials on RODC) because some applications won't allow cached credentials on client computer
For client computers its regular authentication from RODC, for RODC it is cached credentials
This will also help you to avoid client authentication over WAN link

One last thing, if you wanted to test if RODC is working as expected, set above GPO of cached logons to 0, remove all alternate DNS entries from client, disconnect RODC connectivity to R/W DC's (RODC should remains online) and then try to logon through new account which you have never used for logon on machine before and see if it can logon?
It will not, because even if you allowed password replication for those accounts, RODC cannot connect to R/W DC to cache its credentials because 1st time RODC need to connect to R/W DC to cache account credentials
RODC will allow logins to only those accounts for which he has cached credentials

Mahesh.
Please clarify what you are after.
RODC is the read-only replica DC so changes/updates to account/records can only be done on other DCs RODC will forward any change requests.

I am unclear what you are raising.

Are you trying to preclude/prevent Admin accounts from being populated on the RODC?
Seemingly counter to the RODC purpose. It is designed to be placed at a branch office without exposing an attack vector on the AD.
One with physical access to a DC can gain access and then issue updates to AD records that will propagate/replicate to others.

If a branch where an RODC is deployed loses access/connection to the master DC network, what do you expect?.
You could set a shorter password expiration age for administrative accounts........
Please ref write-up on RODC and the purpose for it
https://technet.microsoft.com/en-us/library/cc755058(v=ws.10).aspx
Avatar of monkfish72

ASKER

I am testing by disconnecting the server from the network and still logging in as an admin account that is explicit denied form having its password cached on the RODC server

To the replies telling me the purpose of the RODC, thanks but I know the purpose and its exactly why I am using an RODC - the problem I have is the RODC is not doing what it should with regards to the password replication policy

I have a password policy to limit the accounts that have the password stored on the server - it appears to just ignore this policy and cache every single domain account - thats the problem I am having, nothing else

The server appears to know this policy - checking the 'resultant policy' for a specific account states it is denied from being cached on the RODC server - but it still caches the account - the account appears in the list of 'accounts whose password are stored on this read-only domain controller'
I think you are misinterpreting.  Try the following, attempt the same test using a workstation.
The data on the RODC is not cached it is an actual copy of the AD data repository.
Cached is only on workstations or member servers not DC or RODC.

I understand what your setting is for (though that requires the hacker being already in-house), I.e. Prevent a workstation into which an admin logged in from being taken off network and then attempting to determine the password.
No that is not what the RODC password replication policy is for - the DC itself is in a site with vulnerable security - I want to prevent the DC being taken and used to get all our accounts and passwords

To do this I use a PRP to prevent admin passwords being cached - this is the default for an RODC anyway - but it is not working

please see here - admin accounts cannot cache by default - but my admin accounts (and other accounts are)
https://technet.microsoft.com/en-us/library/cc730883(v=ws.10).aspx

I have no interest in workstations - this is about the DC
Can you create new admin ID (member of domain admins) on r/w DC, replicate it to RODC (normal AD replication) and once ID is available on RODC, can you disconnect network connectivity and try to logon on RODC - now since this user never logged on RODC, he should not be able to logon

If it does, it means it is taking its password from AD database on RODC and then we can think for further

Mahesh
Hi Mahesh - thats exactly what I tried at first - I assumed it was wrongly reporting that is was being cached - but an account with admin rights can log on to the domain on the RODC with the network cable unplugged - so it is definitely caching the account on the server
additional info - to 'force' the replication to the RODC I logged on as the admin account whilst is was networked - it then cached it allowing logon when disconnected

of course the replication of the password to the server should never have taken place!
Ok now try below

Based on your testing RODC is not caching password to logon on itself, but its directly picking it from AD database on RODC server, I have not tested this but it seems like that
If you did not caching user password, may be he is domain admins, then he will be restricted to logon to domain workstations if RODC is not available, but you cannot restrict users from logging on to RODC directly if they are part of domain admins or any other group which grant them rights to logon to RODC
Hence MS has allows you to destroy RODC any time from R/W DC regardless of his status offline / online

Mahesh.
Lets try this scenario for size. An issue occurs in the branch where they need to perform administrative tasks on the workstations in the branch. Unfortunately, your connection to the HQ/Writeable DC is lost.

Your Policy renders any administrative task at the branch unavailable.

The document indicates that the Password replication policy has to be created prior to the RODC
"When you initially deploy an RODC, you must configure the Password Replication Policy on the writable domain controller that will be its replication partner. "
Meaning if you have multiple-writeable DCs the policy has to be configured on each with which this RODC might be connected.

Double check your replication policy an administrative user that is also a member of an allowed list might have their credentials replicated and stored .........
I am fully aware of the pros and cons of an RODC, thats not what I am asking about here!  For us the possible lack of maintenance at a small site during a connectivity outage is not as important an issue as the fact that an RODC could be stolen giving somebody full access to every account on our domain! - inlcuding enterprise admins!

As regards the PRP unless I remove the rules saying 'do not deny admin account' it does not matter what other rules I have - I can have 10 rules saying allow the account to cache - the one saying deny will always win
ASKER CERTIFIED SOLUTION
Avatar of arnold
arnold
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
could not find anything indicating the 2003 forest/domain would cause the issue - but Arnold has so thats the solution, thanks
2003 forest/domain was the issue - Arnold provided link
have you raised domain / forest functional level to 2012?

Does your issue got resolved?

Mahesh.
I think the original issue was you have not issued adprep /rodcprep command

Because you may have upgraded AD from 2003 server or you have directly added 2012 servers in new domain with 2003 DFL and FFL, you must need to run adprep /rodcprep

https://technet.microsoft.com/en-us/library/cc771055(v=ws.10).aspx

If now your issue is resolved after updating functional levels, may be rodcprep command would not be required anymore
U may run command to see if get executed
Mahesh, without adprep, the addition of the 2012 DC (adprep /forest /domain /schema using the win2012 media), the attempt will fail/be denied with a message to run adprep. The same is true for setup of an RODC which would not be permitted if adprep /rodcprep was not run on the master DC.

The issue is that the feature/restriction that is being attempted does not work in AD 2003 domain/forest level without regard whether there are 2012 read/write DCs. For the enforcement to work, the Domain/forest functional level must be 2008 or higher as detailed in the provided link within the RODC writeup link .
@Arnold:
The issue is weird and not able to identify immediately, but you cracked it.

Many thanks for explanation

Mahesh.