We have a branch office in Costa Rica where, back then, we had implemented a Squid proxy with SSO using AD and it was working perfectly. Just recently we implemented an RODC at the site. Once that happened, no one was able to authenticate and I haven't been able to fix the issue. I've deleted the AD object used for the kerberos authentication and ran this command:
msktutil -c -b "CN=COMPUTERS" -s HTTP/PROXY.domain.com -k /etc/squid3/PROXY.keytab --computer-name PROXY-K --upn HTTP/PROXY.domain.com --server dc1.domain.com --verbose
This command actually creates the object in AD but doesn't set the password. I get the following error:
Error: krb5_set_password_using_ccache failed (Cannot contact any KDC for requested realm)
Error: set_password failed
I've made sure that this machine can resolve the domain controllers.
At this point, I'm lost. Been battling this for a month on and off and could really use some guidance. I have four other identical squid proxies that don't sit behind an RODC and work perfectly.
Best Answer
I'm assuming that the RODC is functioning correctly, i.e.: Kerberos is OK, AD DS up and running, Etc.?
I think my next step would be to capture a network trace, filtering just DNS and Kerberos, and then see what the client(s) are doing.
--- 07/01/2017 ---
I can see a Kerberos handshake taking place between the 172.26.48.25 and 172.21.1.19. However, two AS-REQ (authentication service request) responses fail, with a regularly seen KRB5KDC_ERR_PREAUTH_REQUIRED. This is expected ONCE with Kerberos 5. Seeing it twice is odd, and normally indicates time synchronisation problems between the KDC and Kerberos client.
However, we then see the client request a service ticket. The ticket-granting service (TGS) part of the KDC responds with KRB5_NT_UNKNOWN (Kerberos name type unknown). I'd therefore perhaps investigate this error a little more, as I wouldn't normally expect the client to steam ahead with requesting a service ticket if its initial authentication had failed.