locked
UAG and Kerberos single sign-on - Restricted Path or HTTP 401 Request Failure RRS feed

  • Question

  • Hello,

    Been trying to get an internal WebDAV server published via UAG without much success.  Here's the app list:

    UAGPortal
    DNNPortal
    WebDAVPortal
    *others, including RemoteApps/RemoteDesktop

    DNNPortal and WebDAVPortal are both on the same internal server but use different dns names and IP's resolving to different websites in IIS- both are listening only on https.

    Internally these apps are used like so:
    dnnportal.mydomain.local (NTLM)
    webdavportal.mydomain.local (kerberos) - needs to be this way because it uses windows auth and maps various user shares on file servers

    Everything works fine internally, and dnnportal.mydomain.local is publishing fine and SSO's from UAG with no problem.  webdavportal on the other hand presents me with one of two errors.

    WebServers tab:
      webdavportal.mydomain.local
      paths: /WebDAVStorage/

    Web Settings tab:
      X Allow Data using WebDAV methods
      X Allow POST without a content header

    Authentication tab:
      X Use Single Sign-On
      X Use Kerberos constrained Delegation for Single sign on
      X http/*

    The rest is default aside from specifing https://webdavportal.mydomain.local/WebDAVStorage/ in Application tab

    Results:
    Browser -
    You have attempted to access a restricted URL.
    The URL contains an invalid path.
    Navigate back and follow another link, or type in a different URL.

     

    Web Monitor -
    A request from source IP address 99.42.211.X on trunk MyTrunk; Secure=1 for application WebDAV Portal of type WebDAV failed. The URL /WebDAVStorage/ contains an illegal path. The rule applied is Default rule. The method is GET.

    Same Config but with a forced SPN of
    Authentication tab:
      X Use Single Sign-On
      X Use Kerberos constrained Delegation for Single sign on
      X http/webdavportal.mydomain.local


    Browser-
    You do not have permissions to view this folder or page.

    Web Monitor-
    The request from user web\\zcook at source IP address 99.42.211.X to trunk MyTrunk; Secure=1 failed because the request was unable to reply to an HTTP 401 request from application WebDAV Portal of type WebDAV. The session ID is 445761F7-758B-4264-AE6B-EF63B34BF645.

    I'm at a loss as to where to go from here...

    Tuesday, June 8, 2010 4:10 AM

Answers

  • Zachary, I'm marking this question as answered, even though it is not, because it has been here for many weeks with no answer. I would suggest you re-post it as a new question, with a summary of this thread, and hopefully, it will get noticed and answered.

     


    Ben Ari
    Microsoft CSS UAG/IAG Support
    Sammamish, WA
    • Marked as answer by Erez Benari Thursday, September 2, 2010 8:53 PM
    Thursday, September 2, 2010 8:53 PM

All replies

  • Ok I got ahead of myself on the Restricted Path.

    The rule had a different path for the application earlier, which I had renamed.  It looks like UAG (Update 1)'s rules didn't update the authorized URLs list in advanced trunk settings when I renamed.  I did that manually and that error is gone when using http/* and login to the main app works.

    I do get an access denied whenever I hit any of the mapped virtual directories though.  What account(s) should I place an SPN against for UAG to properly delegate so those will work?

    2008 R2 domain

    UAG, Webserver, File server all on 2008 R2.

    UAG directory service account is service~unified

    Tuesday, June 8, 2010 4:33 AM
  • I believe this to be a straight up kerberos error now but am not sure, and would love some insight as to how to confirm and especially how to fix.

    webdavportal.mydomain.local is on an IIS7.5 server running successfully with an SPN tied to a service account for farm config. 
    SPN's are
    http/webdavportal.mydomain.local
    http/webdavportal

    I've set contrained delegation in AD for UAG01 machine account to allow delegation to the above SPNs

    I've configured UAG like so

    WebServers tab:
      webdavportal.mydomain.local
      paths: /WebDAVStorage/

    Authentication tab:
      X Use Single Sign-On
      X Use Kerberos constrained Delegation for Single sign on
      X http/webdavportal.mydomain.local
    and also tried:

    Authentication tab:
      X Use Single Sign-On
      X Use Kerberos constrained Delegation for Single sign on
      X http/*

    It is not able to authenticate to the application.  Leaving these in web monitor:

     Information - 121 - KCD Protocol Transition Succeeded Security UAG01 The S4U2Self Kerberos token for user zcook was retrieved successfully. The application is WebDAV Portal of type WebDAV on trunk MyTrunk; Secure:1.

     Warning - 24 Application Authentication Failed Security MyTrunk (S) UAG01 The request from user mydomain\\zcook at source IP address 172.16.1.254 to trunk MyTrunk; Secure=1 failed because the request was unable to reply to an HTTP 401 request from application WebDAV Portal of type WebDAV. The session ID is 06239900-C360-4C35-8DCD-EC859FB6D440. 

     Information - 5 Application Accessed Application MyTrunk (S) UAG01 The application WebDAV Portal was accessed on trunk MyTrunk; Secure=1 with user name mydomain\\zcook and session ID 06239900-C360-4C35-8DCD-EC859FB6D440.

    It works if I don't specify use Kerberos, but then I can't access any of the virtual directories as those require the client to connect with kerberos so that delegation can succeed and avoid the NTLM double hop.  Stressing again that this app works just fine with kerberos if connected with a browser supporting it and configured to do so.

    Tuesday, June 8, 2010 7:04 PM
  • The account ( identity under web application running webdav) will be the account the SPN's need to be created against.

    EG

    say i have a website called test.test.local internal Running with a domain account called webdav the command would be as follows

    setspn -a http/test test\webdav

    setspn -a http/test.test.local test\webdav

     

    Ontop of setting the SPN's for the site against an account you also need to change the authentication Provider of the site in IIS.

    This can be done by running the following command:

    c:\inetpub\adminscript

    cscript adsutil.vbs set w3svc\"Website ID"\NTAuthenticationProviders "Negotiate,NTLM"

    EG. cscript adsutil.vbs set w3svc\1\NTAuthenticationProviders "Negotiate,NTLM"

    The service accounts and machines also need to be trusted for delegation ( Once an SPN has been set to the host the delegation tab will become available in active directory users and computers, select the machine and trust for delegation.

    Also confirm the website is using intergrated authentication.

    if you need more assitance feel free to send me an email. braden_voigt@hotmail.com

     

    • Proposed as answer by braden Voigt Wednesday, June 9, 2010 6:21 AM
    • Unproposed as answer by Zachary Cook Wednesday, June 9, 2010 5:43 PM
    Wednesday, June 9, 2010 4:41 AM
  • There is also several tools you can use to fault this.

    For windows 2003 - Authdaig

    For windows 2008 - Setspn has new features for testing

    Kerbtray

     

    You can also enable kerberos logging

    Create reg key under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\ Kerberos\Parameters  

    Dword 

    LogLevel =1

     

    You may also hit another issues saying packet size too big, this is because kerberos 5.0 uses UDP not TCP. To resolve this issue add the below reg key into the same path as above.

    Dword

    MaxPacketSize =1

    Wednesday, June 9, 2010 4:46 AM
  • Thank you for the reply.

    The SPN's for the application already exist and are working when accessed from IE with network access enabled.  Kerberos is confirmed in 2 ways:

    1. DelegConfig v2 reports full success
    2. Virtual directories mapped to UNC shares work fine - if it were using NTLM this would fail due to the double hop issue.

    The web app SPNs are set against a service account as you have suggested.  And is using the useAppPoolCredentials flag in applicationhost.config as suggested in this article for running a web farm requiring kerberos authentication.
    http://blogs.msdn.com/b/webtopics/archive/2009/01/19/service-principal-name-spn-checklist-for-kerberos-authentication-with-iis-7-0.aspx 

    It seems for one reason or another though, that UAG isn't able to authenticate like other clients can.  I'll try firing up kerbtray and see if perhaps I can get more details on why UAG specifically is failing to authenticate.

    Wednesday, June 9, 2010 3:26 PM
  • Turns out I actually had forgot to remove the kerberos logging from the internal web server so it was already logging.
    There don't appear to be any kerb errors around time of logon attempts?

    Kerbtray seems to just show the tickets for my user account, and not computer account issued tickets.  Is there something I need to configure with that?

    I do notice that when internal clients hit the site the authentication is instant - there's no username/password prompt it just logs in automatically.

    Could :

    "unable to reply to an HTTP 401 request from application " be a literal meaning?  If so... how do I either A: Force IIS to prompt before authenticating or B: Tell UAG to just see if a 200 status was sent?

    Wednesday, June 9, 2010 3:48 PM
  • Ok I enabled Kerberos logging on UAG01 server as well now and did see a kerb error.  Upon an authentication attempt this is in the logs:

    KDC_ERR_S_PRINCIPAL_UNKNOWN

    I have tried setting :

    Authentication tab:
      X Use Single Sign-On
      X Use Kerberos constrained Delegation for Single sign on
      X http/webdavportal.mydomain.local

    and

    Authentication tab:
      X Use Single Sign-On
      X Use Kerberos constrained Delegation for Single sign on
      X http/*

    What SPN should I place there? 
    Running setspn -Q http/webdavportal.mydomain.local from UAG01 returns the results I'm expecting. 

    setspn -q http/webdavportal.mydomain.local
    Checking domain DC=mydomain,DC=local
    CN=service~webdav,OU=Service Accounts,DC=mydomain,DC=local
            HTTP/webdavportal
            HTTP/webdavportal.mydomain.local
            HTTP/app03
            HTTP/app03.mydomain.local

    Existing SPN found!

    Is there another SPN specific to UAG single sign on that needs to be created?

    Wednesday, June 9, 2010 4:48 PM
  • I fired up netmon and the request from UAG that's returning the KDC_ERR_S_PRINCIPAL_UNKNOWN is :
    ldap/mydomain.local

    setspn -q confirms that no such SPN exists.  Domain and forest level is 2008 R2.  Is that something that was in older domain levels that I should maybe put in?

    I also see it requests host/uag01.mydomain.local which succeeds.

    I do not see an attempt at http/webdavportal.mydomain.local at all.

    Only other KRB errors are ERR_PREAUTH_REQUIRED which I believe to be irrelevent as they come up all over the place and don't seem to have any ill effects elsewhere.

    Wednesday, June 9, 2010 8:38 PM
  • Ok... I got this figured out.  Not sure if it's a bug or by design but this is what fixed it.

    I found here:
    http://technet.microsoft.com/en-us/library/ee690462.aspx
     If the application's SPN in the application server is defined as a host name, Forefront UAG translates it to two SPNs: a hostname and an FQDN with the Forefront UAG Domain Name System domain.

    So I figured that maybe despite the trace not showing it UAG was auto appending the FQDN onto my already specified FQDN in the servers tab.
    WebServers tab:
      webdavportal.mydomain.local
      paths: /WebDAVStorage/

    So I adjusted it to this:
      webdavportal

    And boom.  Now it's working fine.  I had put the FQDN in because this traffic is encrypted based on internal certs depending on FQDN.  Putting just the hostname in the webservers tab and leaving the FQDN in the application tab allows kerberos to succeed and UAG still uses the FQDN to access the app so SSL cert still is error free.

    • Marked as answer by Zachary Cook Wednesday, June 9, 2010 8:56 PM
    • Unmarked as answer by Zachary Cook Wednesday, June 9, 2010 9:56 PM
    Wednesday, June 9, 2010 8:56 PM
  • I had fooled myself... setting the servername to be the short name while leaving the URL long didn't correct the issue.  What it did was disable HAT and allow the request to pass directly to it. Obviously this doesn't work as external machines won't be able to hit the internal URL.

    I turned off SSL for testing - verified kerberos works just fine for http://webdavportal/ from other clients.  Configured that as the webserver and the URL.  It's once again failing to login.  I did a new network trace and verified that I've returned to this point:

    I fired up netmon and the request from UAG that's returning the KDC_ERR_S_PRINCIPAL_UNKNOWN is :
    ldap/mydomain.local

    setspn -q confirms that no such SPN exists.  Domain and forest level is 2008 R2.  Is that something that was in older domain levels that I should maybe put in?

    I also see it requests host/uag01.mydomain.local which succeeds.

    I do not see an attempt at http/webdavportal.mydomain.local at all.

    Only other KRB errors are ERR_PREAUTH_REQUIRED which I believe to be irrelevent as they come up all over the place and don't seem to have any ill effects elsewhere.


     

    Wednesday, June 9, 2010 10:06 PM
  • Ok... I got this figured out.  Not sure if it's a bug or by design but this is what fixed it.

    I found here:
    http://technet.microsoft.com/en-us/library/ee690462.aspx
     If the application's SPN in the application server is defined as a host name, Forefront UAG translates it to two SPNs: a hostname and an FQDN with the Forefront UAG Domain Name System domain.

    So I figured that maybe despite the trace not showing it UAG was auto appending the FQDN onto my already specified FQDN in the servers tab.
    WebServers tab:
      webdavportal.mydomain.local
      paths: /WebDAVStorage/

    So I adjusted it to this:
      webdavportal

    And boom.  Now it's working fine.  I had put the FQDN in because this traffic is encrypted based on internal certs depending on FQDN.  Putting just the hostname in the webservers tab and leaving the FQDN in the application tab allows kerberos to succeed and UAG still uses the FQDN to access the app so SSL cert still is error free.

    You should have 2 http/ SPN's per host name.

    http/webdavportal.mydomain.local
    http/webdavportal

    So you are no longer getting any KDC_ERR_S_PRINCIPAL_UNKNOWN errors?

    And you have confirmed its working without any issues from a desktop inside your environment?

     

    Hmmmmm got to love kerberos, it always casues issues.

    Do you have a sharepoint environment, you can create a site on and enable kerberos?

    Was thinking if you create the site expose it over UAG confirm that sharepoint works running kerberos behind UAG, then you know its most likely not the UAG server that has the problem but more like something around webdav, however if it doesnt work could look into more detail around your portal application.

     

    Wednesday, June 9, 2010 11:38 PM
  • You should have 2 http/ SPN's per host name.

    http/webdavportal.mydomain.local
    http/webdavportal

    So you are no longer getting any KDC_ERR_S_PRINCIPAL_UNKNOWN errors?

    And you have confirmed its working without any issues from a desktop inside your environment?

     

    Hmmmmm got to love kerberos, it always casues issues.

    Do you have a sharepoint environment, you can create a site on and enable kerberos?

    Was thinking if you create the site expose it over UAG confirm that sharepoint works running kerberos behind UAG, then you know its most likely not the UAG server that has the problem but more like something around webdav, however if it doesnt work could look into more detail around your portal application.

     

    I do have these SPNs in place - here's the results of setspn -q webdav

    Running setspn -Q http/webdavportal.mydomain.local from UAG01 returns the results I'm expecting. 

    setspn -q http/webdavportal.mydomain.local
    Checking domain DC=mydomain,DC=local
    CN=service~webdav,OU=Service Accounts,DC=mydomain,DC=local
            HTTP/webdavportal
            HTTP/webdavportal.mydomain.local
            HTTP/app03
            HTTP/app03.mydomain.local

    Existing SPN found!

    webdavportal being an alternative name (configured against dns A record) and app03 being the server name.

     

    Netmon shows me that UAG is never even requesting this SPN though.  It is first checking for an ldap/mydomain.local record and failing to find that.  It doesn't attempt to find the SPN I have configured in the authentication tab, which I can only assume is due to this lookup failing.

    As mentioned - this is a 2008 R2 domain level.  I'm wondering if that SPN was in place by default on older domain levels.  When you setspn -Q ldap/child.mydomain.local or ldap/mydomain.local do you see any results?

     

     

    Thursday, June 10, 2010 12:47 PM
  • Ok - I was able to come up with a couple different domains that are 2003 domain level and check for the ldap/mydomain.local style records and there none.

    I have completely removed this application from UAG, saved config, applied config, then re-added it.  The problem stands and netmon still shows the same thing:

    PREAUTH failure for the user attempting to login.
    PREAUTH failure for the UAG01 machine account.
    KDC_ERR_S_PRINCIPAL_UNKNOWN for ldap/mydomain.local

    No attempts at hitting the http/ SPN for the application.  The pre-auth failures are no big deal I'm sure... but why is UAG looking for that ldap SPN and what exactly can I do to create it?  I don't want to go creating ldap/ SPN's for testing... I'm not familiar enough of kerberos to know what ill effects that might cause.

    Thursday, June 10, 2010 5:08 PM
  • You will need to create the LDAP SPN (ldap/mydomain.local)

    setspn -a ldap/DC1.mydomain.local

    OR setspn a ldap/LDAP.mydomain.local ( create a cname for ldap to point to DC  )

    Launch ADSIEdit.msc and select the properties of the domain controller.  You will want to add the other DNS name to the following attribute on the DC Computer object.

    msds-additionalDnsHostName 

     

     

    Some SPNs create by default some dont, Depends on the application.

    What authentication are you using on ur authentication Depository in UAG?

    Can you also confirm the time on all these servers are correct too (Related too PreAuth failure).

     

     

     

     

    Thursday, June 10, 2010 11:49 PM
  • The ldap SPN it is querying for isn't a domain controller or specific host name.  It is actually for the domain name itself.

    Authentication for UAG is Active Directory - titled simply ADAuth - though when I select the option for kerberos it doesn't let me use a UAG repository.

    For grins though the repository is configured like so:

    * Use Active Directory forest authentication

    Base DN: DC=mydomain,DC=local
    * Include subfolders
    * Level of nested groups : 10

    Specifiy creds used to access AD for retrieving user info and changing passwords
    mydomain\service~unified
    password: aValidPassw0rd

    Friday, June 11, 2010 6:52 PM
  • Time config appears to be syncing perfectly across the forest - manually checked all dc's, UAG01, and the internal web server I'm trying to publish.
    Friday, June 11, 2010 6:56 PM
  • I changed the auth config from * Use Active Directory forest authentication to specifying individual domain controllers.  This has removed the spn call to ldap/mydomain.local.

    In looking at the trace closer - the PRE_AUTH failures are immediately followed by a 2nd request which succeeds.  I think all I'm seeing there is run of the mill kerb negotation.

    Netmon still doesn't show UAG attempting to use an SPN to login to the underlying app server.
    UAG still logs the following:

     Information - 121 - KCD Protocol Transition Succeeded Security UAG01 The S4U2Self Kerberos token for user zcook was retrieved successfully. The application is WebDAV Portal of type WebDAV on trunk MyTrunk; Secure:1.

     Warning - 24 Application Authentication Failed Security MyTrunk (S) UAG01 The request from user mydomain\\zcook at source IP address 172.16.1.254 to trunk MyTrunk; Secure=1 failed because the request was unable to reply to an HTTP 401 request from application WebDAV Portal of type WebDAV. The session ID is 06239900-C360-4C35-8DCD-EC859FB6D440. 

     Information - 5 Application Accessed Application MyTrunk (S) UAG01 The application WebDAV Portal was accessed on trunk MyTrunk; Secure=1 with user name mydomain\\zcook and session ID 06239900-C360-4C35-8DCD-EC859FB6D440.

    I'm at a total loss as to what else to try now...

    Monday, June 14, 2010 6:35 PM
  •  Warning - 24 Application Authentication Failed Security MyTrunk (S) UAG01 The request from user mydomain\\zcook at source IP address 172.16.1.254 to trunk MyTrunk; Secure=1 failed because the request was unable to reply to an HTTP 401 request from application WebDAV Portal of type WebDAV. The session ID is 06239900-C360-4C35-8DCD-EC859FB6D440. 

     


    That error above makes me think there is a problem with Webdav.

     

    It seems your clients are having no issues connecting, see below.

    Information - 121 - KCD Protocol Transition Succeeded Security UAG01 The S4U2Self Kerberos token for user zcook was retrieved successfully. The application is WebDAV Portal of type WebDAV on trunk MyTrunk; Secure:1.

     

    Secure=1 failed because the request was unable to reply to an HTTP 401 request from application WebDAV Portal of type WebDAV.

    So Webdav is giving UAG a 401.

     

    Did you change the authentication Provider to "Negotiate,NTLM" ?

    Have a look at this link, it may help you out.

     http://blogs.iis.net/bretb/archive/2008/03/27/How-to-Use-DelegConfig.aspx

    Tuesday, June 15, 2010 5:37 AM
  • Also all ur DNS records are A records?

    Tuesday, June 15, 2010 5:41 AM
  • Access attempts are all standard browser requests at this phase... I haven't even started testing webdav clients yet.

    DNS records are all A records.

    DelegConfig reports no issues.

    How do I contact the UAG support team?  I now believe this issue may be specific to UAG.

    Tuesday, June 15, 2010 2:03 PM
  • Bump on this for support guys.  Issue is summarized as such:

    Publishing generic web application
    Web application works with kerberos authentication from normal clients. - Confirmed many times over.
    When UAG tries to authenticate to it there's a failure with this in web monitor:

    Warning - 24 Application Authentication Failed Security MyTrunk (S) UAG01 The request from user mydomain\\zcook at source IP address 172.16.1.254 to trunk MyTrunk; Secure=1 failed because the request was unable to reply to an HTTP 401 request from application WebDAV Portal of type WebDAV. The session ID is 06239900-C360-4C35-8DCD-EC859FB6D440. 

    UAG's computer account has appropriate constrained delegation permissions in AD.  The SPNs it's delegating to are attached to a user service account and not a computer account.  This is required due to the sites nature - similar to sharepoint requirements.

    When running a netmon I no longer see kerberos errors - but I do see UAG attempting to authenticate to the presented 401 (using negotate protocol) and failing to pass the credentials (source app replies to UAG with another 401 using NTLM)

    Friday, June 18, 2010 3:09 PM
  • Zachary,

    I just built ur solution in my test environment.

    Im not getting any issues at all. However i did notice it doesnt like DFS, had a large amount of trouble getting that too work with WebDav.

    I would recommend you call Microsoft Support and log a service ticket, they maybe able to supply you with remote assistance.

     

     

     

    Wednesday, June 23, 2010 11:15 PM
  • That's really interesting... with UAG in front I'm not even getting as far as webdav testing.  Just trying to auth to a simple default.aspx page via standard web protocols.

    I also tried another server behind UAG and I get the same results.  I then tried using a different public host name and still... the same results.

    Are you able to pull this off against IIS7.5 on the inside? 

    Once again, netmon shows no sign of kerberos issues from UAG, and I can see with netmon that the authentication prompts do appear properly a couple times.  It seems as if UAG is not responding to the prompts appropriately because the internal application is shown to be serving the unauthorized pages in response which is also confirmed with netmon.

    Wednesday, July 14, 2010 12:54 AM
  • Zachary, I'm marking this question as answered, even though it is not, because it has been here for many weeks with no answer. I would suggest you re-post it as a new question, with a summary of this thread, and hopefully, it will get noticed and answered.

     


    Ben Ari
    Microsoft CSS UAG/IAG Support
    Sammamish, WA
    • Marked as answer by Erez Benari Thursday, September 2, 2010 8:53 PM
    Thursday, September 2, 2010 8:53 PM
  • Hi Zachary,

    I know it's one year ago, but did you any progress in this case and solved this issue?

    Seems to be we ran in a similar problem.

    Kind regards!

    Friday, August 19, 2011 7:17 PM
  • Hi all,

    I'm having the same troubles with a simple IIS 7.5 configured as Windows Authentication with "Negociate:Kerberos" only protocol.

    We tried everything, even reinstall in a testbed scenario with original DVDs produced the same behaviour.

    UAG is the latest version available. An IE client has no problem to retrieve SPN and authenticate to the IIS web app (which only contains an 'hello world' htm page).

    I experience strictly the same error logs as Zachary, which lead me here while googling for an answer.

    Thank you all for any update to this case.

    Sylvain.

    Wednesday, October 12, 2011 3:43 PM
  • I've experienced a similar problem getting the error message "failed because the request was unable to reply to an HTTP 401 request from application". In my case this was a sharepoint site. We were trying to get SSO to a sharepoint site but got Permissions Denied when opening the application in the UAG portal. It turned out to be a case of missconfiugred KCD delegation. The UAG's computer account was delegated access to the sharepoints Computer account, the SPN were setup and looked ok but we still had problems. The problem was that the Application Pool in the IIS of the Sharepoint was running as a serviceaccount instead of the Network Services. After changing the Delegation of the UAG computer account to the servicesaccount and configuring SPN for the servicesaccount everything started to work. So the SPN in the UAG should be configured to the SPN of the ServiceAccount and the UAG's Computer Account should have delegation to the serviceaccount.

    Best Regards

    /Mattias

    PointSharp

    Wednesday, July 4, 2012 10:41 AM