Kerberos not working for me with AD/LDAP Connector 4.2.3

jholladay · June 5, 2019, 4:14pm

Kerberos worked magically for me on version 4.2.1. I upgraded to 4.2.3 this morning. After fixing the problem with firewall.js (due to a lodash template function signature change), it still doesn’t seem to be working.

When it redirects to the Kerberos port, it’s asking for my credentials (which it didn’t used to do when it was working for me). No matter what I put in for the username, it just keeps asking for my credentials (no error). I’ve tried all of the variations I can think of: holladayj, PFI\holladayj, holladayj@PFI.COM.

When I get redirected to that Kerberos port, it presents me with a screen to enter my credentials. The first time I enter my credentials, this is added to the log:

2019-06-05T15:51:13.368Z - debug: [2019-06-05 15:51:13] auth0: Connection closed.

(2 second delay here)

2019-06-05T15:51:15.453Z - debug: [2019-06-05 15:51:15] Reading CA certificates from Windows Store

2019-06-05T15:51:15.680Z - debug: [2019-06-05 15:51:15] Adding 53 certificates

2019-06-05T15:51:15.682Z - debug: [2019-06-05 15:51:15] Loading settings from ticket: https://dev-wybf4mq5.auth0.com/p/ad/Qa36RyEn/info

2019-06-05T15:51:16.100Z - debug: [2019-06-05 15:51:16] Local settings updated.

2019-06-05T15:51:16.106Z - debug: [2019-06-05 15:51:16] Certificates already exist, skipping certificate generation.

2019-06-05T15:51:16.109Z - debug: [2019-06-05 15:51:16] Configuring connection PFIAD.

2019-06-05T15:51:16.110Z - debug: [2019-06-05 15:51:16] > Posting certificates and signInEndpoint: http://DEV-APP02:51873/wsfed

2019-06-05T15:51:16.441Z - debug: [2019-06-05 15:51:16] Connection PFIAD configured.

2019-06-05T15:51:16.442Z - debug: [2019-06-05 15:51:16] Connector setup complete.

2019-06-05T15:51:16.762Z - debug: [2019-06-05 15:51:16] Cache enabled

2019-06-05T15:51:16.800Z - debug: [2019-06-05 15:51:16] Connecting to wss://dev-wybf4mq5.auth0.com/lo/hub.

2019-06-05T15:51:17.297Z - debug: [2019-06-05 15:51:17] Setup passport.

2019-06-05T15:51:17.631Z - debug: [2019-06-05 15:51:17] Using kerberos authentication

2019-06-05T15:51:17.641Z - debug: [2019-06-05 15:51:17] listening on port: 51873

2019-06-05T15:51:17.947Z - warn: [2019-06-05 15:51:17] jsonwebtoken: expiresInMinutes and expiresInSeconds is deprecated. (x86)\Auth0\AD LDAP Connector\ws_validator.js:323:19)

Use “expiresIn” expressed in seconds.

2019-06-05T15:51:18.069Z - debug: [2019-06-05 15:51:18] auth0: Agent accepted.

2019-06-05T15:51:20.153Z - debug: [2019-06-05 15:51:20] latency test took avg: 334.69 ms, max: 1155.92 ms, min: 239.37 ms

As I enter my credentials several more times, nothing additional appears in the log. If I close the tab and go back in 5 minutes, the whole thing repeats itself. I’m not sure, but it almost looks like it’s crashing and restarting.

If I turn off kerberos, the authentication works fine.

Any help would be appreciated.

Thanks
Jason

nicolas_sabena · June 13, 2019, 1:15pm

Hi Jason.
There seems to be no changes related to Kerberos authentication from 4.2.1 to 4.2.3.

Can you try rolling back to version 4.2.1 to see if Kerberos authentication works again? This way we can confirm it’s a code change and not something happening in the browser.

Thanks,
Nico

jholladay · June 13, 2019, 2:29pm

I’ve reverted to 4.2.1. It’s exhibiting the same negative behavior described in the topic.

nicolas_sabena · June 13, 2019, 2:32pm

Thanks for confirming. That suggests that the problem lies elsewhere.
What browser are you testing this on? Can you try on a different one and report back?

FYI: We just released version 4.2.5 that fixes the lodash/firewall issue and also the troubleshooter package generation issue.

jholladay · June 13, 2019, 2:49pm

It turns out that this behavior is stemming in part from my misunderstanding of the Kerberos IP addresses. I thought it was a value used by the auth0 side of the system, so I put in my public IP address. It turns out that this value is used by the connector. Seems kind of odd that it’s not part of the connector configuration. Anyway, when it’s set to match my local IP address, it works fine.

So it seems that a path related to the specified Kerberos IP addresses is not functioning correctly for me.

Set the kerberos CIDR such that it does not represent my IP address
Attempt to log in using the connection
Nothing I try for username/password works. No errors. Just stuck on the login being presented by the kerberos portion of the AD connector.

One of the strange things about our environment is that the domain name and URN do not match the e-mail address. Also my user name doesn’t match my e-mail address.
email: jholladay@pfic.com
domain: PFI.com
urn: holladayj@PFI.com

Is it possible that something related to this is confusing the login process in this non-kerberos kerberos flow (kerberos on, logging in from a non-matching IP address)

I did just verify that the straight LDAP authentication is working correctly (kerberos just plain off).

I will try with Edge and Firefox.

jholladay · June 13, 2019, 3:04pm

Since I happen to have Kerberos enabled and set up to work correctly for me, I’m testing Chrome, Edge, and Firefox. So I’m testing Kerberos enabled, CIDR matches on my IP address. It should take my Kerberos token and not ask me to sign in.

Chrome works fine.

Firefox made me authenticate via basic http authentication before it would present me with the login screen, which then does not work. So it did not take my kerberos token.

Edge works like chrome with the kerberos CIDR misconfigured. That is, it presents me with the login and nothing I put in works.

I will break the kerberos CIDR and try again with all three browsers.

jholladay · June 13, 2019, 3:04pm

Also firefox whines about not using https for that connector login screen…

nicolas_sabena · June 13, 2019, 3:07pm

The IP address range is used by Auth0 server. If the authentication request comes from an IP that falls in the configured range, Auth0 redirects the browser to the connector’s Kerberos authentication endpoint (https://{connector_server}/wsfed IIRC).
If the user is not in that IP range, Auth0 will ask for the credentials directly (in the hosted login page) and contact the connector to validate those credentials.
The IP range should be the LAN ip addresses where Kerberos authentication is possible (usually the internal network where clients are connected to the AD controller). If you are outside the company’s network then Kerberos won’t work, that’s why Auth0 relies on the IP range to decide whether to attempt a Kerberos authentication or not.

The non-matching urn/email/domain shouldn’t be affecting Kerberos authentication at all…

You said that Kerberos was working for you before. What else changed?

jholladay · June 13, 2019, 3:51pm

What was (and is) working is when Kerberos is enabled, and the CIDR matches my internal IP address, and I’m using chrome, then my kerberos token authenticates me successfully. This does not work at all for me in Edge or Firefox.

What is not working is when kerberos is enabled and the kerberos CIDR does NOT match my internal IP address.

The way you describe it is how I assumed it worked. It does not seem to be working that way. What appears to happen is that if kerberos is enabled, the site redirects to the kerberos port, regardless of the kerberos CIDR’s. Then, when it gets there, if the CIDR matches the (private) IP address on the request, it attempts to use the token. If the CIDR does not match the (private) IP address, the connector presents a login screen.

I can demonstrate this as follows:

My private IP address is 192.168.21.74
Disable Kerberos
Use default universal login screen (disable custom screen)
Click ‘Try’ on my PFIAD connection
I get the universal login screen. No need to go further.
Enable Kerberos
Specify a kerberos CIDR that does not match my private IP address (in this case 192.168.21.75/0)
Click ‘Try’ on my PFIAD connection
I do not get the universal login screen. I get the connector login screen (which still does not seem to work)

I’m also concerned that the kerberos connection (and therefore login screen it presents) is not using https. Doesn’t that expose it to the man-in-the-middle sort of compromise (if nothing else)?

jholladay · June 13, 2019, 4:36pm

As far as I can tell, it is completely ignoring the kerberos CIDR’s. No matter what I put in there, if kerberos is enabled, it will redirect to the kerberos port of the connector and use my kerberos token.

One of my points of confusion is stemming from my solution to the difference between our usernames and e-mail addresses. In the interest of picking something consistent, I modified the AD query to only query on “mailNickName”. While you can customize the query, I don’t see where you can customize the value that it pulls out of the kerberos token to do the lookup. I was hoping it was using the GUID and not using the LDAP query when authenticating with kerberos. What I suspect it is doing is getting the SAM account name from the kerberos token and pushing that into the normal LDAP query, which was failing because that wasn’t in my query. I modified my AD query so that it uses either, and the kerberos token authentication is working all browsers.

Now that it’s working, I’m unable to test how it works when there’s no kerberos token and kerberos is enabled, because the kerberos CIDR’s don’t seem to have any effect. When it was broken, even if I specified my mail nickname (jholladay), it still wasn’t working.

jholladay · June 13, 2019, 4:41pm

I’d like to edit the original topic, as it is now somewhat misleading.

I think the root of my problems are that I removed the sam account name from my LDAP query, and that broke the kerberos authentication mechanism.

I do think that the kerberos CIDR’s aren’t doing anything meaningful, and that there isn’t enough information in the logs to have arrived at the resolution to my problem directly. What happened to me here deserves a mention in the documentation that tells you that you can change the LDAP query. The jury is still out for me on whether that connector login screen actually works. I’ll have to test that tomorrow when I’m off the internal network.

nicolas_sabena · June 13, 2019, 4:47pm

Note that the Auth0 server will receive your public IP address, so the Kerberos range defined for the connection should also be referring to public IP addresses.

Can you send me, via DM, a .HAR file when attempting to use the connection outside the Kerberos IP range? To record, copy the link from the “Try” button and paste it on a new window where you previously opened the network trace in the developer tools (and with “Preserve log” enabled). Please let me know the exact IP range configured at the moment of the recording.

Firefox needs some tweaking to work with Firefox, see Configure AD/LDAP Connector Authentication with Kerberos

jholladay · June 28, 2019, 6:54pm

This issue was resolved with version 5.0.2 of the AD/LDAP connector.

system · July 13, 2019, 6:54pm

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.