Keep in mind that just because you join to the domain as BODC and RODC, ITS STILL A READ ONLY ACCESS. It can’t make changes to the domain, only duplicates the configuration.
A. Is a Steelhead RODC different from a Windows RODC when joined to a domain?
Yes, most of the information regarding Microsoft RODC functionality does not apply to the Steelhead as we do not perform any of the usual RODC operations done by an actual RODC. The Steelhead joins the domain as an RODC so that it will have the elevated privileges that Microsoft provides to RODCs for NTLM pass-through authentication.
When joined as an RODC the Steelhead does NOT do any of the following:
The steelhead does not answer any authentication attempts from any clients.
The steelhead does not cache any user credentials.
The steelhead does not advertise itself as a domain controller (or RODC) via DNS or any RPC mechanisms.
Users should not make any changes to DNS SRV host records which can lead to the server-side Steelhead being advertised as a DC.
The server-side Steelhead will not provide any DC like functionality to other domain members.
Lastly, Why is the Steelhead feature called RODC if it does not act like a Windows RODC?
The Steelhead Appliance uses the privileges assigned to a Read Only Domain Controller to determine the session key for a signed or encrypted connection. All other functions of a Windows Read Only Domain Controller are not used as mentioned above.
Hope this answers some of your questions.
I understand that it is a read-only system.
My only concern is that -if it appears as an RODC in the nltest /dclist - it is advertised as a -real- RODC and a client might think it is providing authentication services (so might send login requests to the riverbed), which will fail of course, since it is not doing any real domain authentication for clients.
How does the client know that it is not a real RODC (providing logon services) if it appears in the list of domain controllers ?
I agree the riverbed must be joined for key interception etc, but i don't want it to appear as in any DC or RODC list when a client enumerated domain controllers for logon....
Get list of DCs in domain <domain>' from xxx
...other real DCs.....
ams.domain.com [RODC] [DS] Site: MSO-AMS
The command completed successfully
I have a customer who just removed his DC Steelhead from the domain due to domain join concerns.
A Microsoft specialist did an AD-check at this customers site. He had concerns when he saw the Steelhead is joining as RODC and recommended to remove it from the domain immediately.
I sent him the Riverbed document "Joining a Steelhead to a domain", which describes the domain join behavior very detailed. Unfortunately, this paper did not destroy all his concerns. Is there such a written statement available from Microsoft ?
Coming back to this old post, since Microsoft specialists are again bothering me: point f. iv. is COMPLETELY wrong. The riverbed IS listed as RODC using nltest /dclist:xxx, so it DOES advertise itself as RODC in AD. However, when a client sends an authentication request to it (think it is a valid rodc), it does not reply. Result: user fails to authenticate in the app.
So a little more in detail:
1) Joining a Steelhead as RODC does not create "domain controller" DNS records inside DNS.
You can verify this by the command "nslookup -type=SRV _ldap._tcp.dc._msdcs.<domain>" or "nslookup -type=SRV _kerberos._tcp.dc._msdcs.<domain>". The Steelhead does not show up.
2) The Steelhead is also not added to the "Domain Controllers" OU in Active Directory schema.
3) However, the Steelhead is added to the "Computers" OU and the "userAccountControl" property sets the "ReadOnlyDC" property. Because of this, the Steelhead shows up when you do an "nltest /dclist:<domain>".
This command does an AD query for "DsGetDomainControllerInfo" and here it is returned. If you have an application that picks at random a server to authenticate from this list, you will have a problem, because the application might think that this device provides authentication services, while it doesn't.
Geert and or Riverbed TAC,
Came across this thread because I am preparing to migrate my SYSVOL from FRS to DFSR and a was told by Microsoft (in passing...was talking to them about a different issue) that I need to do something about all the Steelhead RODCs before I do the migration otherwise I would have problems. So I did some research and found this thread and then the one from MS below.
I am more concerned now than before because no one has responded to Geert. What is the latest on this situation?
Interesting link. I wish i found that before. We have been bitten with the "Knock twice to enter problem" :-)
A sysadmin was running a script daily that connected to all DCs. However, the script failed always on the first run. A second run worked. Root cause was the Riverbed that blacklisted the IP while trying to optimise the session. The first action of "blacklisting" the ip , drops the connection (and returns a "cannot connect" error to the client). On the second try, the ip is already blacklisted so the sessions continues unoptimized. The blacklist times out after 20 min, so the next day, the sysadmin had the same problem again and again. I worked around it by creating a bypass rule for his workstation, but the true solution is to move to end-to-end Kerberos like explained in the above link. However, if you are running a lot of legacy software, end-to-end Kerberos as -only- solution is nearly impossible.
Ha, something is changing.
Checkout bug id 237176
BUG #237176 - GET-ADDOMIANCONTROLLER FAILS AFTER THE STEELHEAD JOINS THE DOMAIN IN RODC MODE.
Get-ADDomianController fails after the SteelHead joins the domain in RODC mode.The fix is to avoid creating an object for the SteelHead in the "CN=Servers,CN=<site-name>,CN=Sites,CN=Configuration,DC=<domain>" object during domain join/rejoin.In case of an upgrade, enter this command to overcome the issue: protocol domain-auth auto-conf win2k8-mode op-type leave adminuser <admin-user> adminpass <admin-password>