Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Clear all filters
Answers

Need an iRule to skip Kerberos Authentication for MAC

While trying to edit a document(excel or a word) on a SharePoint site, Only MAC users are getting a prompt to authenticate, Whereas windows users don't have this problem. Our APM policy doesn't have any Kerberos authentication method. I assume this Kerberos is in-built in MAC OS. I need an iRule to skip this Kerberos authentication for MAC users. Any help is appreciated.

0
Rate this Question

Answers to this Question

placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

This is the Kerberos login prompt MAC users are getting. We need to skip this step by writing an iRule.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

To remove an NTLM or Kerberos authentication challenge, you'd need to catch any 401 responses to the client. But then who is sending these challenges? Is APM configured to authenticate users? And if so, by what method (Basic, NTLM, Kerberos)?

And how do you know which is a Mac and which is Windows, aside the browser User-Agent header?

0
Comments on this Answer
Comment made 27-Sep-2018 by Harrish 54

Hi Kevin, Yes APM is configured to authenticate users. And we have NTLMv2 configured.Image TextImage Text Our application is hosted for external users as well, So when they are trying to authenticate they are clearly coming to backend servers and opening the SharePoint site. The problem is when MAC users try to edit any document then this Kerberos login page appears. Windows users can easily edit the documents without seeing any login page. Now fro MAC users we have to skip that extra Kerberos login page step when they try to edit documnets.

Many Thanks, Kevin

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

So, to be clear, this isn't really a Kerberos logon page. Kerberos itself doesn't require a logon page. What's likely happening is that the the server is not accepting the NTLMv2 SSO that you're passing it from Mac clients, and responding with its own 401 response. And since it's NTLM, the 401 would also contain a "WWW-Authenticate" header with a value of "Negotiate", and so the Mac client is interpreting this as Kerberos, can't comply, and so presents the user with the screen you're seeing.

It's safe to say this screen is not something you've defined as one of your logon pages, correct? And if so, the screen is actually being generated by the client browser in response to the 401.

So basically, you need to look at the server side and determine why the server isn't accepting the NTLMv2 SSO credentials. If you can capture on the client side, using something like Fiddler, you should see a 401 response from the server on Mac clients.

0
Comments on this Answer
Comment made 28-Sep-2018 by Harrish 54

Hi Kevin,

When I check the APM-SSO-Debug logs I can see 401 response for SSO configuration and also www-authenticate header: Negotiate www-authenticate header: NTLM Do you think there is a need to do changes to our SSO Credential mapping and NTLMv2 configurations which should be specific to our organization? Image Text

Image Text

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

So you definitely see a 401 coming from the application server?

The first thing you should probably do is log the username and domain variables and compare between the Mac and Windows clients.

0
Comments on this Answer
Comment made 28-Sep-2018 by Harrish 54

Hi Kevin, Appreciate your help!

These are the SSO config debug logs I see and confirm that I can see 401 response. Image Text

You advised me to log the username and domain variables Can you please guide me how should I do them?

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Right before the end of the policy, add a logging agent that shows session.sso.token.last.username and session.logon.last.domain.

%{session.sso.token.last.username}
%{session.logon.last.domain}
0
Comments on this Answer
Comment made 28-Sep-2018 by Harrish 54

Image Text

Do you mean adding a logging agent right after SSO Credential Mapping?

In the NTLMv2 SSO Configuration, we have as in the picture below

Image Text

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

It should be the last agent in the policy. You want to log the username and domain variables that you’ve defined, and then compare between Mac and Windows.

APM doesn’t care which client you’re using, so the likely cause is that the Mac is sending something slightly different that isn’t getting translated correctly in Credential Mapping.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Uncertain if this helps any? Yet have had to work through a number of on-premise hosted Sharepoint issues last few years for MACs specifically. The following has worked 'mostly' to re-negotiate NTLM. Believe it's still compatible with Office 2016 client apps. Though M$oft change things around...often. E.g.:

when HTTP_REQUEST {
set useragent [string tolower [HTTP::header value "User-Agent"]]
if { ([string length $useragent] < 50) || (($useragent contains "mac") && !($useragent contains "mozilla")) || (($useragent contains "macintosh") && ($useragent contains "microsoft")) }{ 
      if {($sid == "") || ($useragent contains "macintosh")}{
         switch -glob $useragent {              
            "microsoft office" -
            "*microsoft document connection*" -
            "*microsoft office word*" -
            "*microsoft office excel*" -
            "*microsoft office powerpoint*" -
            "microsoft office existence discovery" -
            "microsoft office protocol discovery" -
            "*webdavfs*" -
            "*word*" -
            "*excel*" -
            "*powerpoint*" -
            "*onenote*" -
            "*webdavlib*" {             
               ACCESS::disable
               if { ([HTTP::method] == "OPTIONS") && ([HTTP::header value 
                                Authorization] == "Bearer") }{
                  set mac_auth 1
               } 
            }
         }   
      }
   }
when HTTP_RESPONSE {
   if { ($mac_auth != "") }{
      HTTP::respond 401 WWW-Authenticate "NTLM"
      set mac_auth ""
   }
}
0
Comments on this Answer
Comment made 1 month ago by Nat 12

Actually, I need to peruse these forums more. Here is a far more elegant solution I will also be testing :) https://devcentral.f5.com/questions/office-2016-apm-protected-sharepoint

0