locked
Cross Forest Kerberos Web Application Authentication Issue RRS feed

  • Question

  • Hey All,

     I have been working hard on migrating my company from SharePoint 2010 to SharePoint 2016. With the "2013" hop required it's been a rather annoying ride. Sadly I didn't even want to go this path, but for unforeseen reasons I am stuck taking this path.

    I have created a 2 way trust between my old domain forest and my new domain forest. During my testing I found I was having some initial authentication issues, I was able to work around... See here

    Now creating none duplicate based login names for the two different domains def made automatic logons via the same domain work without a hitch. However as I stated at the end of the previous post, I was stilling getting credential prompts. Sure enough it wasn't A host records, or intranet site settings (those were all good) it came down to SPN's and kerberos delegation. So after correcting the SPN's and re-assigning them to the new service accounts, and specify the Web front end object to trust kerberos for the specified services associated with the SPNs, sure enough automatic logons for the new domain was working a treat.

    The problem was I was still getting pop ups from users and systems in my old domain, which everyone is still authenticating against since I couldn't do a direct cut over to move everyone at once to the new domain.

    To my dismay looking at the kerberos tickets I have on my system (klist) I can see the preauth ticket against my local domain stating it should be forwarded to be granted against the new domain controllers, which is hosting my new SharePoint services. Sadly I don't seem to see this tickets, so you can assume that when I get a cred pop up, enter my creds and the page loads, we can assume one thing... it still reverting back to NTLM.. but WHY!

    So for a temp work around I went to the Web Application settings, and adjusted the Auth providers from Kerberos to NTLM. And sure enough everyone can access the SharePoint Page no probelms... but I want kerberos!!

    Did I configure my SPN wrong? any ideas what I might have missed?

    Tuesday, November 28, 2017 5:58 PM

Answers

  • This sounds more complex than it needs to be, honestly. Setting up SharePoint with Kerberos is easy and does not require delegation. Create the SPN (HTTP/hostname.domain.com) for the Service Account running the Web Application. Change the Web Application to use Kerberos. That's all that is required; the delegation step you took is unnecessary in non-BI scenarios.

    Second, you should be directly assigning users (or AD groups in the same forest with those users) to ACLs in SharePoint for the account they use to logon to their Windows desktop. To prevent auth prompts, you'd need to add the SharePoint FQDN to the Intranet Zone in IE.

    If you're attempting to create *new* accounts in the new forest and using those accounts for ACLs in SharePoint while users still log into their existing accounts in the old forest, yes they'll get credential prompts. Users acquire a Kerberos ticket from the logon process to Windows and those accounts will have no association with accounts in the new forest (nor a Kerberos ticket from the new forest).

    If I've misread something that you have or haven't done, let me know.


    Trevor Seward

    Office Servers and Services MVP



    Author, Deploying SharePoint 2016

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    • Marked as answer by Zewwy Tuesday, December 12, 2017 10:51 PM
    Tuesday, November 28, 2017 6:19 PM
  • Someone screwed up then cause proper nesting is the whole point of proper permission with minimal overhead. It even states there "deep nesting" as well as "may" so I wouldn't consider that a rule of thumb, cause any nesting too deep is bad, much like Nesting hypervisors for testing or otherwise, NAT rules etc.

    That wouldn't be best practice. Best practice is IDGLA which I've been following and cleaning up along the way with the migration. It's key to any place, you really shouldn't be granting permissions directly. It's not best practice.

    Anyway, I managed to figure it out, and I was right all along, it has nothing to do with nesting groups since the issue occured even with direct permissions, but even looking at the wireshark packets it was exactly as I descibed an not requesting the TGT from the proper domain.

    First off, I'll give credit where credit is due. You were right as it's not that complicated to setup, and this is where it gets weird. I was CERTAIN I had configured the SPN properly, but I suppose in the last couple weeks I have been lacking in my documentation and running blind trying to get everything to work. So in my test enviroment, running wireshark, I did notice the missing kerberos connections to Domain.ca domain for the service in question. I double checked the SPN via  "setspn -F -Q */SP2016.domain.ca" and to my amazement it was still referenceing my old SharePoint app identity. (Remember this was a cut over from a whoel old domain to a new domain, where the old domain simply had a zone to handle the new domain web header, but no actual Domain existed for it).

    So I removed the old SPN "setspn -D HTTP/SP2016.domain.ca oldServiceAccount.domain.local"

    Then Added the proper SPN  "setspn -S HTTP/SP2016.domain.ca domain.ca\NewServiceACcount"

    The other thing to note is once this is done, which I did on the old domain DC (domain.local), and you rerun the query for the SPN "setspn -F -Q */SP2016.domain.ca" it will return null, as if it can't find anything. I'm assuming this is normal when querying for a SPN that is hosted in a trusted domain.

    Either way once this was done I checked my wiresharl, and my kerberos tickets (klist) from my client, and sure enough the page loaded without cred prompt, and I saw the TGT I was expecting the whole time!!

    SO, I had to go down the whole nitty gritty, just to find out you were right the whole time, and I didn't properlly set my SPN (even though I was certain I did this). Sooo Important lesson is don't forget to go over the basics again before expecting something even deeper is going on.

    Good learning experience thanks Trevor.

    ONE LAST TAKE AWAY!!**

    Note I got my expected results in my test enviro when I had the systems in questions on two separate networks with a open firewall/router between them. If you are running a proper segregated network setup you have to allow the computer system in question that need to access the services, to allow kerberos from the client to the KDC servers in the other domain. The TGT tickets are not relayed from domain.local DC's to Domain.ca DC's, The Domain.local DC simply reply they don't have authority to grant tickets for the service and than tell the client to query the domain.ca DC's KDC for a proper ticket. So adjust firewalls accordingly.

    Another Note**

    I wasn't receiving the SPN cause I wasn't specifying the other forest using the -T switch of the setspn command:

    Running "setspn -t domain.ca -F -Q */sp2016.domain.ca" from any system in the trusted forest will provide the proper SPN result. Makes sense now that I think about it...

    • Marked as answer by Zewwy Tuesday, December 12, 2017 10:50 PM
    • Edited by Zewwy Wednesday, December 13, 2017 3:29 AM
    Tuesday, December 12, 2017 10:50 PM

All replies

  • This sounds more complex than it needs to be, honestly. Setting up SharePoint with Kerberos is easy and does not require delegation. Create the SPN (HTTP/hostname.domain.com) for the Service Account running the Web Application. Change the Web Application to use Kerberos. That's all that is required; the delegation step you took is unnecessary in non-BI scenarios.

    Second, you should be directly assigning users (or AD groups in the same forest with those users) to ACLs in SharePoint for the account they use to logon to their Windows desktop. To prevent auth prompts, you'd need to add the SharePoint FQDN to the Intranet Zone in IE.

    If you're attempting to create *new* accounts in the new forest and using those accounts for ACLs in SharePoint while users still log into their existing accounts in the old forest, yes they'll get credential prompts. Users acquire a Kerberos ticket from the logon process to Windows and those accounts will have no association with accounts in the new forest (nor a Kerberos ticket from the new forest).

    If I've misread something that you have or haven't done, let me know.


    Trevor Seward

    Office Servers and Services MVP



    Author, Deploying SharePoint 2016

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    • Marked as answer by Zewwy Tuesday, December 12, 2017 10:51 PM
    Tuesday, November 28, 2017 6:19 PM
  • 1) You are correecct I took secondary steps to help try and figure out whats up... didn't work. Just remember it is easy, and was super simple for any user in the SAME domain as the new SharePoint Front end server, the issue is with trusted forest domains.

    2) You are correct and I failed to mention that, I have a group in my old domain (it is a Domain Global Security Group). I have another group in my new domain, it is a Domain Local Security group and granted permission directly on the SharePoint Site permissions. The Old domain global group is nested into the new domain local group, and permissions are indeed apply correctly, so it's not a group nesting issue, it is a kerberos issue.

    3) From my understanding of kerberos it'll first request kerberos tickets for the domain in which a user is in, and then since the service is for another domain, the ticket gets forwarded to the new domain controllers to verify and create a granting ticket for the users in question for the service in question...

    I've been following along with this nice Youtube video that describes all the steps kerberos takes. This is 100% a kerberos issue as the site loads 100% fine once we revert back to NTLM (for old domain users) and kerberos works 100% for any user I create in the new domain and add to that domain local group which has permissions on the SharePoint site.

    If you could elaborate a bit more on your final comment here, I'd greatly apprciate it cause from all the research I've done this SHOULD work...


    • Edited by Zewwy Tuesday, November 28, 2017 7:20 PM
    Tuesday, November 28, 2017 7:17 PM
  • I recently wrote an article on this topic as someone else had questions on how you enable Kerberos for SharePoint Web Apps. The steps outlined here are ALL you need to do in an environment such as yours:

    https://thesharepointfarm.com/2017/10/enabling-kerberos-sharepoint/

    All users would use their existing account, e.g. the "old" domain accounts, if that is what users are logging into Windows with, will be assigned ACLs in the SharePoint farm that is in the new forest.


    Trevor Seward

    Office Servers and Services MVP



    Author, Deploying SharePoint 2016

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Tuesday, November 28, 2017 8:02 PM
  • Yes And I completed those steps. So again not sure why my cross forest  kerberos isn't working...

    http://www.frickelsoft.net/blog/?p=290

    If you look at the deep dive here, which goes more deep into the nitty gritty then your post (I still love your post for its simplicity) however doesn't help when things are not working as they are suppose to. Such as in my case across forests.

    In the link I provided you can see under Steps 5-6... as described...

    "(5) However, when the client computer asks the root Domain Controller for a TGS ticket for the resource in, say, fabrikam.com, the root Domain Controller cannot hand that ticket out. Again, as described earlier, only the resource’s KDC can hand out these ticket. So what the root Domain Controller does is hand out a TGS ticket for the Domain Controllers in the trusted forest’s root domain, fabrikam.com. The root Domain Controller in contoso.com knows that the resource is across the trust, as the DNS name suffix and the trust information are available.

    (6) The client machine now gets the ticket to access fabrikam.com’s Domain Controllers. Via DNS, it figures out their IP addresses and poses a TGS request to one of the fabrikam.com DCs, asking for a service ticket for the external-files.fabrikam.com file server to access its file services capabilities."

    This is exactly where I find Kerberos is failing for me, as I never see these requests or the granting tickets from the root domain which is delegated for the SPN and SharePoint Front end I created.

    Yes, as you mentioned its that easy, and I did the basic steps and IT does work for users in the New domain, I cannot for multiple reason migrate users to the new domain yet. ( I have 100's of other front end servers and services I'd need to migrate first.) So getting Kerberos working here would be very important, I can use NTLM for now but it's not what I wanted moving forward.

      Just so we are on the same page here for the ACL stuff you keep mentioning (which isn't the issue since permissions are granted once fallen back to NTLM)...

    User@oldDomain.com -> (OldDomain.com\Department)[Domain Global Security Group] -> (NewDomain.com\SP Users)[Domain Local Security Group] -> Granted Contribution rights on the entire site.

    Again once users get a prompt and enter their creds once (without fully qualifying their user names; EG. jDoe) The site loads and the permissions are exactly as they should be. So it's not a permissions issue... it's teh fact it's not requesting the TGT from the newdomain.com KDC servers... 

    • Edited by Zewwy Tuesday, November 28, 2017 10:51 PM
    Tuesday, November 28, 2017 10:46 PM
  • Thanks for the help so far Trev,

    I'm going to end up installing wireshark on some of my VM's as well as the VMs in my test enviro and dig a bit deeper. I'll report back my findings. It may take me a couple days to get to the bottom of it.

    Thursday, November 30, 2017 10:31 PM
  • SharePoint doesn't really support group nesting. You also need to make sure that the users are in a group within the same domain as the user, otherwise the user object is a foreign security principal which SharePoint won't understand (that is if DOMA\user is in DOMB\group and DOMB\group is added as an ACL in SharePoint).

    Try also enabling Kerberos debug logging. https://support.microsoft.com/en-us/help/262177/how-to-enable-kerberos-event-logging


    Trevor Seward

    Office Servers and Services MVP



    Author, Deploying SharePoint 2016

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Friday, December 1, 2017 3:39 AM
  • SharePoint Doesn't really support group nesting. That's quiet the statement and from testing appears to work perfectly fine under NTLM.

    Do you have a MS White Paper source for that claim?

    Thanks for the suggestion on Kerberos debugging. It'll help in my analysis, I have yet to get started on as I have to re-vamp my test environment.

    I'll report my findings in the next up coming days. :)

    Thursday, December 7, 2017 3:28 PM
  • It's outlined here.

    https://technet.microsoft.com/en-us/library/cc261972.aspx

    "security groups that have deep nested structure might break SharePoint sites."

    On top of this, managing nested groups is a huge pain. I just migrated a farm away from this due to the complex nesting structure which made permissions management extremely difficult (not to mention identifying who has access to what).


    Trevor Seward

    Office Servers and Services MVP



    Author, Deploying SharePoint 2016

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Thursday, December 7, 2017 4:12 PM
  • Someone screwed up then cause proper nesting is the whole point of proper permission with minimal overhead. It even states there "deep nesting" as well as "may" so I wouldn't consider that a rule of thumb, cause any nesting too deep is bad, much like Nesting hypervisors for testing or otherwise, NAT rules etc.

    That wouldn't be best practice. Best practice is IDGLA which I've been following and cleaning up along the way with the migration. It's key to any place, you really shouldn't be granting permissions directly. It's not best practice.

    Anyway, I managed to figure it out, and I was right all along, it has nothing to do with nesting groups since the issue occured even with direct permissions, but even looking at the wireshark packets it was exactly as I descibed an not requesting the TGT from the proper domain.

    First off, I'll give credit where credit is due. You were right as it's not that complicated to setup, and this is where it gets weird. I was CERTAIN I had configured the SPN properly, but I suppose in the last couple weeks I have been lacking in my documentation and running blind trying to get everything to work. So in my test enviroment, running wireshark, I did notice the missing kerberos connections to Domain.ca domain for the service in question. I double checked the SPN via  "setspn -F -Q */SP2016.domain.ca" and to my amazement it was still referenceing my old SharePoint app identity. (Remember this was a cut over from a whoel old domain to a new domain, where the old domain simply had a zone to handle the new domain web header, but no actual Domain existed for it).

    So I removed the old SPN "setspn -D HTTP/SP2016.domain.ca oldServiceAccount.domain.local"

    Then Added the proper SPN  "setspn -S HTTP/SP2016.domain.ca domain.ca\NewServiceACcount"

    The other thing to note is once this is done, which I did on the old domain DC (domain.local), and you rerun the query for the SPN "setspn -F -Q */SP2016.domain.ca" it will return null, as if it can't find anything. I'm assuming this is normal when querying for a SPN that is hosted in a trusted domain.

    Either way once this was done I checked my wiresharl, and my kerberos tickets (klist) from my client, and sure enough the page loaded without cred prompt, and I saw the TGT I was expecting the whole time!!

    SO, I had to go down the whole nitty gritty, just to find out you were right the whole time, and I didn't properlly set my SPN (even though I was certain I did this). Sooo Important lesson is don't forget to go over the basics again before expecting something even deeper is going on.

    Good learning experience thanks Trevor.

    ONE LAST TAKE AWAY!!**

    Note I got my expected results in my test enviro when I had the systems in questions on two separate networks with a open firewall/router between them. If you are running a proper segregated network setup you have to allow the computer system in question that need to access the services, to allow kerberos from the client to the KDC servers in the other domain. The TGT tickets are not relayed from domain.local DC's to Domain.ca DC's, The Domain.local DC simply reply they don't have authority to grant tickets for the service and than tell the client to query the domain.ca DC's KDC for a proper ticket. So adjust firewalls accordingly.

    Another Note**

    I wasn't receiving the SPN cause I wasn't specifying the other forest using the -T switch of the setspn command:

    Running "setspn -t domain.ca -F -Q */sp2016.domain.ca" from any system in the trusted forest will provide the proper SPN result. Makes sense now that I think about it...

    • Marked as answer by Zewwy Tuesday, December 12, 2017 10:50 PM
    • Edited by Zewwy Wednesday, December 13, 2017 3:29 AM
    Tuesday, December 12, 2017 10:50 PM