How’s user authentication working in a site with a RODC?

So you’re going to deploy an RODC in your branch office to have your users log on there. Are you aware of the process that actually authenticates users on a RODC? When connectivity between the branch and the hub office is needed?

First off, having users authenticate to the machines is not all you need. You probably know that Kerberos is the authentication protocol that’s used with Active Directory by default. In Kerberos’ world, there are a few rules. One of those rules is that, if you don’t have a ticket, you’re not allowed to play. You need them for all services in the domain. For certain services, even computers need to authenticate to Active Directory in order to perform certain tasks. It is therefore necessary that you, if you need users to log on to the domain even if the connection between branch and head office is broken, you have computer credentials cached (and probably pre-poluated) on the RODC, too. More on that now:

So, what happens when a machine is turned on and a user is going to access a share on a file server in the same site? In this case, we assume that neither password of the user and the machine is currently stored on the RODC. We’ll keep it simple in the following scenario. There’s more to the whole process then just “asking for authentication” as described below. Kerberos a little more complex than shown here.

User/Machine authentication

User and machine authentication works pretty much identically. From DNS and the DCLocator process, the client figures that the RODC is the authoritative authentication source for its site (1). It requests to be authenticated by the RODC. The RODC checks its database to see whether it has already stored the user’s/computer’s credentials (2). Since this isn’t the case, it’ll use the WAN connection (3) and forward the auth request to a writeable DC. Since the writable DC knows about the credentials in question, it’ll check them (4) and, if the password provided was correct, it’ll send back the response to the RODC (5) which will happily provide the successful auth (6) to the user/computer. By that time, the client’s request is serviced — but the RODC isn’t happy about not being able to process the auth request on its own. In order to do better, it’ll request the user’s/computer’s credentials from the writable DC – to be able to perform the authentication on its own. The writable DC checks the Password Replication Policy to get to know whether RODC is allowed to cache that password. If so, DC replicates the credentials to RODC which happily stores them in its local database.

Now, the RODC is able to authenticate the user/computer if there was a WAN outage. Before the special password replication (that doesn’t take place during normal rep), RODC wouldn’t be able to service the client’s request if the WAN link was down.

Ticket aquisition/service access

Since we’re using Kerberos, every time we’re trying to access a service in the domain, we need to aquire an access ticket. Domain Controllers (or: the Key Distribution Center, KDC on the DC) hands out those tickets – we just need to request them. In this request, we need to present the KDC a ticket we aquired upon successful authentication. We need to have a ticket to request a service ticket, so to speak. Once we have that service ticket, we can turn around and ask the service to grant us access. Looking at the ticket, the service can tell whether we’re someone allowed or someone denied. If there’s a RODC involved, it performs additional actions before it hands those tickets out:

The user needs to perform changes to a document that’s hosted on the file server. In order to access the file, the user needs to aquire a service ticket for the file server’s services. The user requests the ticket from the RODC (1). Unfortunately, the RODC didn’t authenticate the user as we’ve seen in our example above (2) – the writable DC did. The ticket the user received during authentication can’t be read by the RODC – it is therefore forwarded to the writable DC (3). The writable DC checks the ticket(4) and the ticket request and constructs a service ticket for the user (5). If we were using a “normal” DC here, this would be the time when the user gets this ticket. Not so with the RODC. The RODC notices that service ticket aquisition took place successfully and that it already has the user’s password stored. Now it performs a trick: it tells the user that the service ticket aquisition went wrong (6). At the same time, the user is dropping all his tickets and starts over authenticating as a whole (7) completely from scratch. It requests authentication from the RODC which happily accepts and authenticates (8)- it knows the credentials now. Since the user still wants to access the file server, it computes another service ticket request and sends it to the RODC (9). The RODC this time is able to read the authentication ticket presented by the client as it this time authenticated the user. It can compute its own valid serivce ticket to present it to the client (10). The client now has his service ticket – time to turn around and present it to the file server (11) to finally get access to the file.

You’re confused? Good – that’s what I wanted. Now go take a nap, come back and read the whole thing again. It’ll make sense then. This is how authentication works if passwords/credentials aren’t propagated to the RODC (yet). If you’re going to have your RODC installed in a site, make sure the WAN link is up long enough to have the RODC cache most of the user’s/computer’s passwords – or pre-populate them using repadmin as described in – but we’re going to touch credential pre-population in another posting.

No Comment