Поделиться через

SharePoint 2010 locking out accounts

  • Статья

The User Profile Service - System Job to Manage User Profile Synchronization timer job leverages the winnt:// protocol to lookup an account’s SID.  This call uses WINS and RPC to do the lookup.  If you do not have WINS configured on the SharePoint server, and there is not a DC in the same subnet, you get “The network path was not found” in the SharePoint Logs every time this job runs…which is every minute.  This job takes the permissions set on the User Profile Service Application and applies those permissions to the Forefront Identity Manager components that manage the synchronization process.

The winnt:// call is being investigated, and hopefully we’ll see a change in an upcoming cumulative update.  The workaround in the meantime is to use an LMHosts file on the SP2010 box to point to a domain controller.

My customer was seeing an account lockout as a result of the winnt:// call.  This additional symptom was mainly caused by the customer’s network configuration, but is a side effect I wanted to share just in case anyone else has a similar configuration.

  • 2 domains
     
    • TailSpin – Production domain
    • Contoso – Test environment domain
       
      Contoso trusts TailSpin.  Tailspin does not trust Contoso
       
  • 2 accounts, same name, different passwords 
     
    • Contoso\svcMossDBAccess
    • TailSpin\svcMossDBAccess
       
  • SharePoint 2010 Server joined to Contoso for testing. All Services are using Contoso accounts.
     
  • Timer Service process [owstimer.exe] runs as Contoso\svcMossDBAccess
     
  • In this customer’s scenario, Contoso does not have WINS.  When they setup a new server, they use TailSpin’s WINS Servers in the NIC config.

This was routing the winnt:// account lookup call to a TailSpin server.  Since the winnt:// call uses RPC, pass through authentication is trying to authenticate the TailSpin account with the Contoso password resulting in a locked account.  Since the timer job runs every minute, if you unlock the account, it gets locked within a few minutes (depending on the lock out policy).  Also, the TailSpin account is running their production SharePoint 2007 farm.

We cleaned up the NIC configuration, but we were still getting requests routed to the Tailspin domain and the account continued to get locked out.  This is likely caused by the WINS call falling back to DNS.  To workaround this issue, we created unique service accounts for SharePoint 2010 in the Contoso domain, then used Configure service accounts in Central Administration to change out the service accounts in SharePoint.  I did hit a snag with the User Profile Synchronization Service, and also received word of Search not working after changing accounts.  Here’s a brief rundown of what I hit with these services. 

User Profile Service – The symptom I hit was the User Profile Synchronization Service would show Starting for minutes, then go back to stopped.  The account was in the local admin group, and the box had been rebooted since adding it to the group.  We were using a SQL named instances, and there’s a known issue there, so that may have played a part here.  [Named instance issue is fixed in the SharePoint 2010 June Cumulative Update that should be out soon]

Since this was a new test environment, I went with an aggressive approach:

  1. Stopped both User Profile Services [the Sync service was already stopped…]
  2. Deleted the User Profile Service Application and associated databases
  3. Created a new User Profile Service Application
  4. Start User Profile Service
  5. Start User Profile Synchronization Service

A bit aggressive, but got the job done.  I wouldn’t recommend being so drastic if there’s production data in there :-)

Search - The main symptom was the web parts on the Search Administration page throwing errors.  This is never a good sign as it indicates the search configuration is messed up.  Along with that symptom, queries would result in errors as well.  This was a bit easier to get back online. 

  1. Restarted the SharePoint Server Search 14 service in the Services MMC
  2. Browse the Search Service Application
  3. Click Farm Search Administration
  4. Click Modify Topology
  5. Click Apply Topology Changes
  6. Search Admin web parts all start working, crawls work, and query is working