none
Cannot connect UPS to domains that have Network Security: LDAP Signing Requirements set to 'Negotiate Signing'

    Question

  • Environment:

    Windows 2008 R2 Server with SharePoint 2010 Enterprise in a resource domain

    Multiple Windows 2008 R2 Domains managing various user organizations, some with  Network Security: LDAP Signing Requirements set to 'Negotiate Signing' and some are not due to the organization's particular security requirements

    One-Way trust with the multiple domains, resource domain trusting organization's domains

    Situation:

    When attempting to create an AD connection in the user profile service, for those domains which have the Network Security: LDAP Signing Requirements set to 'Negotiate Signing', the AD connection dialog box errors out with "Strong authentication required..." For those domains which do not have this set, the AD connection setup works just fine. Additionally, when running a scripted modification of the SharePoint User Groups and adding groups within the organization's domain, the script cannot find the groups when running 'Ensure-User' cmdlet. For those environments which have Network Security: LDAP Signing Requirements set to 'None', all works fine.

    Question:

    What can I do to allow UPS to connect to the organization's domains WITHOUT changing the Network Security: LDAP Signing Requirements setting to 'None'? I am not sure if I were to export a self-signed certificate from the resource domain's SharePoint server and import it into all of the organizational domain servers or vice-versa, would that work, or if I were change the Network Security: LDAP Signing Requirements to 'Negotiate Signing' on the SharePoint App server if that would work, but then would it break the connection to the organizational domains that have that setting to 'None'.

    I cannot change the setting as each organization that has this set requires it to be as such.

    I am sure that this has been dealt with before, but I cannot seem to find anything on the 'net that addresses this issue. I have however found some references to setting up a CA, then issuing all certs for all domains from that CA. That solution is not possible in this scenario as some of the domains are already using their own CA with no upstream root.


    Mikol Westling "For those who say it cannot be done; Get out of the way of those that are doing it!"

    Thursday, September 26, 2013 10:45 PM

Answers

  • Ok, a new day and viola, Microsoft pushed down a couple of security patches that apply to LDAP and AD, but despite not directly addressing this issue, may have inadvertently fixed the issue since there were no changes that occurred between yesterday and today. 

    Links to the two security bulletins are listed below:

    http://technet.microsoft.com/en-us/security/bulletin/ms13-032

    http://technet.microsoft.com/en-us/security/bulletin/ms13-079

    I am going to mark this as answered. if anyone is having this same issue, get these two patches, it may help. Trevor, thank you for your help and patience. 


    Mikol Westling "For those who say it cannot be done; Get out of the way of those that are doing it!"

    • Marked as answer by mikolwestling Wednesday, October 02, 2013 7:58 PM
    Wednesday, October 02, 2013 7:58 PM

All replies

  • Negotiate Signing should just be that, negotiate the use of signing.  However, have you validated that your SharePoint server trusts the certificate issued to the domain controllers involved in negotiating signing?

    Trevor Seward, MCC

    Follow or contact me at...
      

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

    Friday, September 27, 2013 12:52 AM
    Moderator
  • I am unsure how to do this. Each of the domains that the SP server is connecting to is a separate forest and there is no root CA issuing certs to the forests. How would I go about either a) validating that the SP server trusts the certs or, b) Make the SP server trust the certs? I have my suspicions, but am not sure.

    Mikol Westling "For those who say it cannot be done; Get out of the way of those that are doing it!"

    Friday, September 27, 2013 1:51 AM
  • I would just import the certificate chain (even if self-signed) into the SharePoint server(s) Local Computer certificate store.

    Trevor Seward, MCC

    Follow or contact me at...
      

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

    Friday, September 27, 2013 3:53 AM
    Moderator
  • I imported the cert chain from the DC's of the offending domains into the SP server's local store and no luck. 

    I have rebooted the server, etc. and am still getting the "Strong authentication is required for this operation" error message when attempting to setup a synchronization connection in CA. 


    Mikol Westling "For those who say it cannot be done; Get out of the way of those that are doing it!"

    Tuesday, October 01, 2013 8:08 PM
  • Can you run a network trace from the SharePoint server creating the sync connection?  It would be interesting to know if the SSL/TLS negotiation is failing, or if there is another issue.

    Trevor Seward, MCC

    Follow or contact me at...
      

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

    Tuesday, October 01, 2013 8:29 PM
    Moderator
  • Ok, did a network trace and the only thing that looks suspect is an LDAP response of: "comment: the server requires binds to turn on integrity checking if SSL\TLS are not already active on the connection". 

    Chasing that down, there is an article about using LDP.exe to test the connection. When using a 'Bind with credentials' and Encrypt traffic after bind' which should emulate the SP non-ssl connection, I do get the same error. When I select 'Encrypt traffic after bind' then I am able to access the domain and query the structure. 

    So, what this seems to me is that the configuration setting to 'Encrypt traffic after bind' when setting up an AD connection in UPS is not being enabled and therefore the LDAP server on the AD that I am trying to connect to is refusing further communications. If this is true, I cannot seem to find where to set this on the SP server so it will work.


    Mikol Westling "For those who say it cannot be done; Get out of the way of those that are doing it!"

    Tuesday, October 01, 2013 9:46 PM
  • There are two options with the UPSS: Sign and Encrypt traffic, or Enable SSL.

    Trevor Seward, MCC

    Follow or contact me at...
      

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

    Tuesday, October 01, 2013 9:51 PM
    Moderator
  • Hmmm... so that means that if I don't have the 'Use SSL' option checked, then it should already be signing and encrypting the traffic just like I discussed when using LDP? If that is the case, then either I am heading down the wrong rabbit trail, or something is either broken or not configured correctly. 

    As a note, UPS is working for all domains that are not hardened by STIG guidelines and are generic Win2008 R2 installs. I am almost thinking that there is another configuration item somewhere on the failing domains but I haven't been able to find it. 


    Mikol Westling "For those who say it cannot be done; Get out of the way of those that are doing it!"

    Tuesday, October 01, 2013 9:58 PM
  • Can you provide the Active Directory STiG guidelines (if the site isn't shutdown at the moment:))?  I have the SharePoint STiGs, but none of the others.

    Trevor Seward, MCC

    Follow or contact me at...
      

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

    Tuesday, October 01, 2013 10:00 PM
    Moderator
  • Ok, so I lied. The test domains that I am able to connect to are not setup like the others, including those that have not been STIGed. So, with that said, it isn't the STIG process that is killing this. The non-STIGed domain is exibiting the same behavior and errors including when using LDP. 

    This happens whether or  not I have imported the certificates. 


    Mikol Westling "For those who say it cannot be done; Get out of the way of those that are doing it!"

    Wednesday, October 02, 2013 12:01 AM
  • BTW, the NIST site is down, but DISA is still up. 

    http://iase.disa.mil/stigs/os/windows/u_windows_2008_r2_dc_v1r8_stig_benchmark.zip


    Mikol Westling "For those who say it cannot be done; Get out of the way of those that are doing it!"

    Wednesday, October 02, 2013 12:02 AM
  • Update:

    Upon further testing, it was discovered that in fact changing the Network Security: LDAP Signing Requirements setting to 'None' does in fact allow the UPS New Synchronization Connection dialog and the UPS to connect to another domain. When relaxing this setting from 'Negotiate signing' to none, it has to be completed at the GPO level and it must be pushed out. You cannot do this at the local policy level.

    Now, with that said, we have tried importing the certificate chain from the domain controller(s) we are trying to connect to and am getting the dreaded "Strong authentication required..." message when attempting to setup a new connection. This is verified using LDP.exe with the setting 'Encrypt traffic after bind' enabled. So, the assumption is that SP and/or UPS is not encrypting the traffic after binding to LDAP on the target AD controller like LDP.exe is when you enable the setting.

    So, herein lies the question, how do you change the behavior of SP to encrypt the traffic after it has bound to LDAP on the target AD controller in the UPS? Would this be a global setting somewhere in FIM or is there some magical, mystical setting somewhere in or behind SP that would change this behavior? We cannot relax this setting in our environment. 


    Mikol Westling "For those who say it cannot be done; Get out of the way of those that are doing it!"

    Wednesday, October 02, 2013 1:21 AM
  • There are only two settings for FIM (in SharePoint): SSL, or Sign and Encrypt.  However, I have the setting in my domain set to Require Signing, although I have the Domain Controller: LDAP server signing requirements set to None.  Either way, in this environment, but SSL and non-SSL function with the UPSS.

    Trevor Seward, MCC

    Follow or contact me at...
      

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

    Wednesday, October 02, 2013 2:01 AM
    Moderator
  • Ok, sounds like the path I would like to go "Sign and Encrypt" but how do I set it to do that. It does not seem that UPS is doing that automagically based upon the remote DC's setting of Negotiate signing.

    Mikol Westling "For those who say it cannot be done; Get out of the way of those that are doing it!"

    Wednesday, October 02, 2013 2:03 AM
  • If you don't set it to use SSL, it uses Sign and Encrypt.

    What is the value of "Domain Controller: LDAP server signing requirements" in the Group Policy covering the Domain Controllers in question?


    Trevor Seward, MCC

    Follow or contact me at...
      

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

    Wednesday, October 02, 2013 2:05 AM
    Moderator
  • It is set to Require Signing which makes me think that there is something with UPS and/or FIM that is either not set or not abiding by the AD DC requirements. 

    Mikol Westling "For those who say it cannot be done; Get out of the way of those that are doing it!"

    Wednesday, October 02, 2013 4:38 PM
  • Ok, a new day and viola, Microsoft pushed down a couple of security patches that apply to LDAP and AD, but despite not directly addressing this issue, may have inadvertently fixed the issue since there were no changes that occurred between yesterday and today. 

    Links to the two security bulletins are listed below:

    http://technet.microsoft.com/en-us/security/bulletin/ms13-032

    http://technet.microsoft.com/en-us/security/bulletin/ms13-079

    I am going to mark this as answered. if anyone is having this same issue, get these two patches, it may help. Trevor, thank you for your help and patience. 


    Mikol Westling "For those who say it cannot be done; Get out of the way of those that are doing it!"

    • Marked as answer by mikolwestling Wednesday, October 02, 2013 7:58 PM
    Wednesday, October 02, 2013 7:58 PM