Thread Info
  • State Suggested Answer
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 4 subscribers
  • Views 9409 views
  • Users 0 members are here
Options
Suggested

NTLM Kerberos Authentication ?

James Panther

Hello Team,

I was going through this new feature implementation i.e. kerberos authentication in which I have notice few things after configuration that I would like to clarify:-

 

1) If we configure browser based proxy with device Hostname then it is going through Kerberos authentication and we are getting AD-SSO Kerberos in live user page

2) If we configure browser based proxy with IP address then it is going through NTLM  authentication and we are getting AD-SSO NTLM in live user page

3) For transparent connection in which I am not configuring any thing in browser proxy then by default it is taking AD-SSO NTLM and not kerberos

Is this above details are as in known behavior or am I missing something?

Parents
  • 0

    Can some please reply on this query?

     

    It is really important for implementation of AD-SSO as I want to understand how exactly it works

  • 0 in reply to James Panther

    James,

    I attach what comes form the v18 EAP 1 course:

  • 0 in reply to lferrara

    Thanks for reply Iferrara, but still I am looking for proper working for the below questions

     

    1) If we configure browser based proxy with device Hostname then it is going through Kerberos authentication and we are getting AD-SSO Kerberos in live user page

    2) If we configure browser based proxy with IP address then it is going through NTLM  authentication and we are getting AD-SSO NTLM in live user page

    3) For transparent connection in which I am not configuring any thing in browser proxy then by default it is taking AD-SSO NTLM and not kerberos

     

    Is this above details are as in known behavior or am I missing something?

  • 0 in reply to James Panther

    Hello James,

    the behavior you describe is absolutely correct. If you require Kerberos authentication, you must always use the internal domain FQDN for the proxy server. If you use the IP address of the proxy server, the authorization is automatically switched to NTLM.

    Of course you have to meet several other conditions in the settings (connect XG to MS AD domain, activate web authentication, define correct settings in the Admin console and end-user interaction field) but the behavior you describe is correct.

    Regards

    alda

  • 0 in reply to alda

    Now, If that behavior is correct I've observed few more things as well for which If some one can clarify :-

    1) If I am using Direct Proxy with Hostname or IP address then, I am getting NTLM logs in awarrenhttp.log file which is correct and in browser also I am getting 307 based redirection

    2) If I am using Transparent Proxy in which If I configure below setting then behavior are different

      i) System => Administration => Admin settings => When redirecting users to the captive portal or other interactive pages is configure as IP address then we are getting NTLM logs in awarrenhttp.log and in live user it is showing as NTLM

     ii) System => Administration => Admin settings => When redirecting users to the captive portal or other interactive pages is configure as hostname then we are getting NTLM logs in ips.log and in live user it is showing as Kerberos

    Is this behavior correct or not ? Why are we getting different logs by making this changes? And what is exact working behaviour in transparent and direct proxy?

  • 0 in reply to James Panther

    The way Kerberos works (part of the Kerberos spec) is that the client is willing to authenticate with a server that has a SPN (Service Principal Name) in the AD Domain.

    When the XG joined the domain it got a name like "myxg.myADdomain".

    Now if myxg.myADdomain ever asks to do "Negotiate" (Kerberos/NTLM) authentication, the client checks and finds there is an SPN for that and sends the client the Kerberos ticket.

    Now if 192.168.1.1 ever asks to do "Negotiate" (Kerberos/NTLM) authentication, client checks and sees no SPN for 192.18.1.1.  Since none is found, it then falls back to doing NTLM.

     

    On the windows computer:

    setspn -Q *myxg*

     

     

    You should see two HTTP entries, one for the bare hostname and one for the hostname.ADdomainname.  NOTE: This might be different from the hostname/FQDN that you filled in on the Administration > Admin Settings page.

    For Kerberos / Transparent

    The Administration > Admin Settings > Admin console and end-user interaction must be one of the two SPNs.

    For Kerberos / Standard

    The proxy server configured on the client must be one of the two SPNs.

Reply
  • 0 in reply to James Panther

    The way Kerberos works (part of the Kerberos spec) is that the client is willing to authenticate with a server that has a SPN (Service Principal Name) in the AD Domain.

    When the XG joined the domain it got a name like "myxg.myADdomain".

    Now if myxg.myADdomain ever asks to do "Negotiate" (Kerberos/NTLM) authentication, the client checks and finds there is an SPN for that and sends the client the Kerberos ticket.

    Now if 192.168.1.1 ever asks to do "Negotiate" (Kerberos/NTLM) authentication, client checks and sees no SPN for 192.18.1.1.  Since none is found, it then falls back to doing NTLM.

     

    On the windows computer:

    setspn -Q *myxg*

     

     

    You should see two HTTP entries, one for the bare hostname and one for the hostname.ADdomainname.  NOTE: This might be different from the hostname/FQDN that you filled in on the Administration > Admin Settings page.

    For Kerberos / Transparent

    The Administration > Admin Settings > Admin console and end-user interaction must be one of the two SPNs.

    For Kerberos / Standard

    The proxy server configured on the client must be one of the two SPNs.

Children
No Data
Unfiltered HTML