Jump to content

NetScaler Kerberos client vs. userPrincipalName


Kari Ruissalo

Recommended Posts

Hi,

 

I have built a SAML IdP according to this blog and I have issues with the internal vServer Kerberos. To be more specific, the issue is with the nFactor LDAP attribute extraction.

 

The customer has modified their userPrincipalNames to match their email addresses. So for instance:

Domain FQDN:  ads.customer.com

Email-suffix: customer.com

sAMAccountName: user1

userPrincipalName: first.last@customer.com

 

So when the internal vServer is authenticating the user and extracting the attributes using the nFactor, the process goes (I assume) like this:

 

  1. User has an existing Kerberos ticket and goes to the vServer for authentication, the Kerberos ticket contains the client name
    Cached Tickets: (1)
    
    #0>     Client: user1 @ ADS.CUSTOMER.COM
            Server: krbtgt/ADS.CUSTOMER.COM @ ADS.CUSTOMER.COM
  2. The user authenticated and then the extracted user name is passed on to the nFactor (user1@ads.customer.com)
  3. nFactor LDAP attribute extraction policy is hit and it queries for user1@ads.customer.com, but can't find it as the users userPrincipalName is first.last@customer.com
  4. Authentication fails

 

I figured that one way around this would be to just use PowerShell to add the Kerberos format username in to an attribute in AD, but this would require the customer to add this attribute for each new user in AD. So is there a way to construct this value somehow for nFactor processing and avoid adding that extra attribute?

 

Link to comment
Share on other sites

11 hours ago, Vamsi Krishna Kanduri said:

Hi Kari,

 

Any reason of using the sAMAccount not UPN?

 

Two changes here.

1. Configure LDAP IP as LB VIP and point to the Actual LDAP server

2. create a rewrite policy to change domain name from ads.customer.com to customer.com

 

Thanks,

Vamsi

 

Well I´d prefer using UPN but the Kerberos seems to send a user name that doesn´t match that one (explained in the initial post).

 

I´m already using LB for the LDAP but can´t understand how should i rewrite the request before passing it to the actual LDAP server? Using sAMAccountName would be the best option here as we should only get rid of the @ads.customer.com at the end of the username (assuming that Kerberos extracts the username as ”sAMAccountname@ads.customer.com”)?

Link to comment
Share on other sites

  • 2 months later...
  • 9 months later...
On 1/27/2019 at 10:42 AM, Ronny Lier said:

Hi Kari,

 

could you solve the problem?

 

We have the same problem and it would be helpful if you could share your solution.

 

Thanks,

Ronny

 

Hi Ronny, not the prettiest solution, but I reserved one extensionAttribute for this purpose and created a scheduled PowerShell which constructs the extensionattribute for each user "{samaccountname} + {domainFQDN}".

 

Initially I had this script filtering out users with extensionAttribute filled in, but I learned quickly that it needed to also check that it's properly filled (users change their last names etc...)

 

There was no actual solution for this one unfortunately or a way to construct the attribute in NetScaler (12.0 firmware).

Link to comment
Share on other sites

Hi Kari,

 

thanks for your feedback. I have solved the problem using nFactor.

 

I configured a login schema (no schema) with the User Expression "HTTP.REQ.USER.NAME.BEFORE_REGEX(re#@#)" before the LDAP request.

This modified the extracted user name from "{samaccountname} + {domainFQDN}" to "{samaccountname}".

 

I use NetScaler 11.1 but the solution also would work with 12.0.

Link to comment
Share on other sites

  • 1 month later...
On 2/1/2019 at 11:11 PM, Ronny Lier said:

Hi Kari,

 

thanks for your feedback. I have solved the problem using nFactor.

 

I configured a login schema (no schema) with the User Expression "HTTP.REQ.USER.NAME.BEFORE_REGEX(re#@#)" before the LDAP request.

This modified the extracted user name from "{samaccountname} + {domainFQDN}" to "{samaccountname}".

 

I use NetScaler 11.1 but the solution also would work with 12.0.

 

Oh. That's pretty neat, I need to give that a go. Thanks for sharing!

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...