Kerberos, web services and getting married!

No, not me… I’ve been happily married for 19 years.. it’ll be 20 while I’m at the SharePoint Conference too, but that’s another story.. watch this space for more details on that one..

The marriage part in this post is something that has been the bane of SharePoint admins for a long time, and that is how to manage when members of staff get married and change their surnames. How this affects you really depends on how your company handles the event. Do they create a new AD account with the new name, do you keep the old AD account and alias the e-mail box? Or do you rename the AD account to the new surname.

The company that I’m doing some consulting for at the moment had these problems, but with a twist. They fully understood what needs to happen in SharePoint 2007 when an AD account is changed. They were using a profile import, then the migrate user command.. (I’m not convinced this step is required.. but I need to test further.) and finally they were making sure that the internal timer job “Profile Synchronisation” for the web application was running hourly.

The upshot is, Jane Doe, became Jane Smith across all the sites she was active in, visible in the hidden user list and displaying the correct details in the user menu.

As soon as she clicked through to the LOB system though she received access denied. The Kerberos tickets were valid on her client machine and SharePoint was happy, however the LOB reported invalid login back to the user.

On investigation, we discovered that the LOB was reporting an attempted login by JANE DOE, who didn’t exist now, therefore it couldn’t match her account to it’s list of acceptable users. After a bit of binging around, we came across http://support.microsoft.com/kb/946358 which describes the problem nicely.

Disabling the LSA cache achieved what we wanted, however I’m always loathe to disable caching willy nilly.. after all caching is there for a reason and usually a pretty good one. In this case it prevented the LOB system from placing a call to AD with every transaction, which prevents an awful lot of AD traffic.

We restored the cache and ran another user through the system, changing their name and ensuring that they couldn’t log in to the new system. After much testing, we discovered that if you run the following 2 lines of powershell, it re-writes the cache entry in the LSA cache, updating it with the correct username. Running this on the Web servers for the LOB system updated the cache properly and the user logged straight in.

This has now been adopted into the clients account name change process.

$objuser = new-object system.security.principal.ntaccount "domain\<new account name>" 
$objuser.translate([system.security.principal.securityidentifier])

I hope this proves of use to you.

Paul.

3 comments

  1. So it turns out that the migrate user step is really important in web farms as it updates the audiences that are compiled on the machine that DOESN’T host the SSP in 2007.

    Without this step, only the SSP contains the correct account in the audience, connecting to other web server results in the audience information being wrong and the web parts not displaying.

    Paul.

    • Christian on Thu 10 Nov 16 at 8:12 pm
    • Reply

    Hi Cimares.

    Thanks for your blog article.

    We encounter an error when running the second line from the above article.

    The command –> $objuser.translate([system.security.principal.securityidentifier])

    Yields the error:

    $objuser.translate([system.security.principal.securityidentifier])
    Exception calling “Translate” with “1” argument(s): “Some or all identity references could not be translated.”
    At line:1 char:19
    + $objuser.translate <<<< ([system.security.principal.securityidentifier])
    + CategoryInfo : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : DotNetMethodException

    So my question is …do you happen to know what the correct command line should be?

    Please advise.
    Thanks.

    Regards,
    –Christian.

    1. Hi Christian,

      This blog is from 2012 and the issue affects upto Windows Server 2008 R2 according to the MS TechNet article that we were using. What server OS are you having the issue on?

      It’s possible that with the advances in identity since 2008, this method no longer works. The key would be to perhaps turn off the LSA cache as per the MS article and see if that resolves your problem, if it does then caching is still the issue but a new method may be needed to resolve it.

      Paul.

Leave a Reply

Your email address will not be published.

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.