none
SSL Certificate installation for Content SSA not working.

    Question

  • I'm getting an error message when trying to install the certificate from the FAST Admin server onto the SP Farm Admin server.  I've verified the account mentioned is the same one that is used when running the SharePoint Server Search 14 service.  In fact, I've tried a few other accounts (such as the content access account and the FAST Admin account), but keep getting the same error message.

    Any ideas or suggestions?

    PS C:\temp> .\SecureFASTSearchConnector.ps1 -certPath "c:\temp\FASTSearchCert.pfx" -ssaName "FS4SP10Content" -username "DEMO\$demoSP10"
    Enter the certificate password: ***********
    Installed certificate.
    Could not set access rights on certificates private keys. Script can be rerun to only set access rights when reason for error is detected.
    Exception -  System.Security.Principal.IdentityNotMappedException: Some or all identity references could not be translated.
       at System.Security.Principal.NTAccount.Translate(IdentityReferenceCollection sourceAccounts, Type targetType, Boolean forceSuccess)
       at System.Security.Principal.NTAccount.Translate(Type targetType)
       at System.Security.AccessControl.CommonObjectSecurity.ModifyAccess(AccessControlModification modification, AccessRule rule, Boolean& modifie
       at System.Security.AccessControl.CommonObjectSecurity.AddAccessRule(AccessRule rule)
       at AddAccessRule(Object , Object[] )
       at System.Management.Automation.DotNetAdapter.AuxiliaryMethodInvoke(Object target, Object[] arguments, MethodInformation methodInformation,
    ] originalArguments)
    Exception calling "AddAccessRule" with "1" argument(s): "Some or all identity references could not be translated."
    At C:\temp\securefastsearchconnector.ps1:204 char:21
    +         $acl.AddAccessRule <<<< ($accessrule)
        + CategoryInfo          : NotSpecified: (:) [], ParentContainsErrorRecordException
        + FullyQualifiedErrorId : DotNetMethodException


    Garth Grimm
    Avery Ranch Consulting
    www.averyranchconsulting.com
    Wednesday, September 14, 2011 7:37 PM

Answers

  • Hi,

    The issue is the $ which acts as the starting point of a variable when used inside double quotes in PowerShell. If you replace the double quotes with single quotes it will work. Single quotes will not expand variables.

     .\SecureFASTSearchConnector.ps1 -certPath "c:\temp\FASTSearchCert.pfx" -ssaName "FS4SP10Content" -username 'DEMO\$demoSP10'
    

    Regards,
    Mikael Svenson 


    Search Enthusiast - SharePoint MVP/WCF4/ASP.Net4
    http://techmikael.blogspot.com/
    • Marked as answer by gdgrimm Thursday, September 15, 2011 9:23 PM
    Thursday, September 15, 2011 8:35 PM
  • So I've found an easy workaround for this issue.

    Instead of passing the username in as DEMO\$demoSP10, I send it in with a ` in front of the $, which causes the script to keep the $ around in the username:

    DEMO\`$demoSP10

    There's probably some other special characters where using ` might be needed.


    Garth Grimm
    Avery Ranch Consulting
    www.averyranchconsulting.com
    • Marked as answer by gdgrimm Thursday, September 15, 2011 8:36 PM
    Thursday, September 15, 2011 8:36 PM

All replies

  • A little more information (and more questions).

    The SharePoint Search Service "type" is running on 2 servers (demoSP10 and demoSP11).  Currently though, the FS4SP10Content service has a topology that only includes demoSP10.  Given that, I should only have to install this certificate on demoSP10, correct?  If I change the topology to include components running on demoSP11, I'll have to install certificates on that machine as well, correct?

    The FAST farm also has 2 servers (demoFS4SP10 and demoFS4SP11), each running its own content distributor.  The FS4SP10Content service is configured to use both of them.  Will I need to run the installer on demoSP10 twice, once to install the cert from demoFS4SP10 and then again to install the cert for demoFS4SP11?

    I'm just using the self signed certs that are created during configuration of FAST.


    Garth Grimm
    Avery Ranch Consulting
    www.averyranchconsulting.com
    Wednesday, September 14, 2011 8:15 PM
  • I walked through the PowerShell script to see what the state of things are when the exception is thrown.  Here's what the ACL is for the installed certificate just before trying to apply the new access rule:

    PS C:\Users\garthgrimm> $acl.Access


    FileSystemRights  : FullControl
    AccessControlType : Allow
    IdentityReference : NT AUTHORITY\SYSTEM
    IsInherited       : False
    InheritanceFlags  : None
    PropagationFlags  : None

    FileSystemRights  : FullControl
    AccessControlType : Allow
    IdentityReference : BUILTIN\Administrators
    IsInherited       : False
    InheritanceFlags  : None
    PropagationFlags  : None

    FileSystemRights  : ReadAndExecute, Synchronize
    AccessControlType : Allow
    IdentityReference : S-1-5-5-0-2822872
    IsInherited       : False
    InheritanceFlags  : None
    PropagationFlags  : None

    Does any of that shed any light on the problem?

    BTW, I've went back and a single node FS4SP farm, and when adding that certificate, I received the same error.  So I don't think the multi-server install of FAST has anything to do with the problem.


    Garth Grimm
    Avery Ranch Consulting
    www.averyranchconsulting.com
    Thursday, September 15, 2011 3:44 PM
  • Hi Garth,

    Quick question, what rights does the user installing the certificate have on the SharePoint server, and did you open the SharePoint Management Shell as administrator?

    Regards,
    Mikael Svenson 


    Search Enthusiast - SharePoint MVP/WCF4/ASP.Net4
    http://techmikael.blogspot.com/
    Thursday, September 15, 2011 7:04 PM
  • So I think I've narrowed down the problem.  It might have something to do with the PowerShell command 'Set-Acl' not being able to  handle more than 30 characters in the username.  http://connectppe.microsoft.com/PowerShell/feedback/details/652360/get-acl-and-set-acl-do-not-handle-names-over-30-characters#details

    Taking some content from that post, I was able to show this on my SP Farm Admin server:

    PS C:\Users\garthgrimm> $allInherit = [System.Security.AccessControl.InheritanceFlags]"None"
    PS C:\Users\garthgrimm> $allPropagation = [System.Security.AccessControl.PropagationFlags]"None"
    PS C:\Users\garthgrimm> $allInherit
    None
    PS C:\Users\garthgrimm> $AR = New-Object System.Security.AccessControl.FileSystemAccessRule("DEMO\$demoSP10", "FullContr
    ol", $allInherit, $allPropagation, "Allow")
    PS C:\Users\garthgrimm> $AR


    FileSystemRights  : FullControl
    AccessControlType : Allow
    IdentityReference : DEMO\
    IsInherited       : False
    InheritanceFlags  : None
    PropagationFlags  : None

    So even though the username was passed in as "DEMO\$demoSP10", the access rule only honored a part of it -- "DEMO\"  That string is exactly 30 characters when "DEMO" is expanded into the full domain name.

    Or it might have to do with the username having a '$' in it.  Since the above seems to work OK when the username doesn't have a '$':

    PS C:\Users\garthgrimm> $AR = New-Object System.Security.AccessControl.FileSystemAccessRule("DEMO\username", "FullContro
    l", $allInherit, $allPropagation, "Allow")
    PS C:\Users\garthgrimm> $AR


    FileSystemRights  : FullControl
    AccessControlType : Allow
    IdentityReference : DEMO\username
    IsInherited       : False
    InheritanceFlags  : None
    PropagationFlags  : None


    Garth Grimm
    Avery Ranch Consulting
    www.averyranchconsulting.com

    • Edited by gdgrimm Thursday, September 15, 2011 7:23 PM More facts found
    Thursday, September 15, 2011 7:08 PM
  • The same Domain Admin account was used throughout (i.e. installing and configuring FAST on the server that the certificate came from, as installing the certificate on the SP server).  So it was a member of the local Administrator group on both servers.

    Yes, the shell was opened as administrator.


    Garth Grimm
    Avery Ranch Consulting
    www.averyranchconsulting.com
    Thursday, September 15, 2011 7:41 PM
  • I've posted some of the relavant information over to the PowerShell forum.  Hoping to see if somebody knows a way to create an access rule that won't mangle the username under the circumstances that I have.

    If I (or somebody else) find one, I'll just rewrite the PowerShell scripts that come with FAST to handle the special case, and use the rewritten ones instead of the ones MS provides.


    Garth Grimm
    Avery Ranch Consulting
    www.averyranchconsulting.com
    Thursday, September 15, 2011 7:54 PM
  • Hi,

    The issue is the $ which acts as the starting point of a variable when used inside double quotes in PowerShell. If you replace the double quotes with single quotes it will work. Single quotes will not expand variables.

     .\SecureFASTSearchConnector.ps1 -certPath "c:\temp\FASTSearchCert.pfx" -ssaName "FS4SP10Content" -username 'DEMO\$demoSP10'
    

    Regards,
    Mikael Svenson 


    Search Enthusiast - SharePoint MVP/WCF4/ASP.Net4
    http://techmikael.blogspot.com/
    • Marked as answer by gdgrimm Thursday, September 15, 2011 9:23 PM
    Thursday, September 15, 2011 8:35 PM
  • So I've found an easy workaround for this issue.

    Instead of passing the username in as DEMO\$demoSP10, I send it in with a ` in front of the $, which causes the script to keep the $ around in the username:

    DEMO\`$demoSP10

    There's probably some other special characters where using ` might be needed.


    Garth Grimm
    Avery Ranch Consulting
    www.averyranchconsulting.com
    • Marked as answer by gdgrimm Thursday, September 15, 2011 8:36 PM
    Thursday, September 15, 2011 8:36 PM
  • That's likely to work as well.  And in that solution, one doesn't even have to know what PS considers a special character.
    Garth Grimm
    Avery Ranch Consulting
    www.averyranchconsulting.com
    Thursday, September 15, 2011 9:23 PM
  • Hey,

    This article might help to troubleshoot your issue..
    http://kalashnikovtechnoblogs.blogspot.in/2012/02/troubleshooting-crawl-issues-for-ssl.html

    Thanks,
    Kalashnikov
    http://kalashnikovtechnoblogs.blogspot.in

    if it helps, Please dont forget to mark it as an answer. Thank you. 
    Friday, February 17, 2012 2:39 PM