2

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.

Lazaro Ravelo
  • 39
  • 8

2 Answers2

0

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.

Simon Catlin
  • 5,222
  • 3
  • 16
  • 20
  • I currently have authentication disabled since I have this proxy in production at the moment. Can't enable it otherwise users will lose access to web. Currently the only DNS traffic I'm seeing in my packet capture are just for websites. Maybe I can try running that command again during a tcpdump? – Lazaro Ravelo Jan 05 '17 at 19:12
  • ok I have here's the wireshark packet capture: https://drive.google.com/open?id=0B2D42hQw4rDLMFdyRDB1U1lfODQ – Lazaro Ravelo Jan 05 '17 at 20:37
  • FYI that trace is between the proxy and one of the writeable domain controllers during the time I ran that msktutil command mentioned in the very first post. – Lazaro Ravelo Jan 05 '17 at 23:24
  • See additions to answer above... – Simon Catlin Jan 07 '17 at 15:15
  • I'm not getting very many results searching for that error message. The time synchronization piece you mentioned is making me think the time is off on the Linux server. I'll have to check that. I did set a different time zone on it. I'll check on Monday when I get back to the office. – Lazaro Ravelo Jan 07 '17 at 20:34
  • ok so it's definitely not an issue with the time. I have the server configured with NTP using the domain controller's time and that doesn't work. I changed the time zone back to Eastern to match what the domain controller has, doesn't work either. – Lazaro Ravelo Jan 09 '17 at 15:22
0

I decided to build a new proxy on a later release of Ubuntu using the latest version of msktutil and it's actually working. I guess I'll just migrate all of the data over and swap IP's during the next maintenance window.

Lazaro Ravelo
  • 39
  • 8
  • Glad to hear u got it working. It may have been a Kerberos encryption type (etype) mismatch, which the later ubuntu release has sorted. – Simon Catlin Jan 15 '17 at 11:01