New-SPSite - Could not find user when using SAML Claims

Question

I have a Host Header web application https://example.com (SharePoint 2013) where users will login from ADFS using SAML Claims.

I am in the process of provisioning multiple site collections for individual tenants using the PowerShell cmdlet New-SPSite

An example of a command I'm running is:

New-SPSite -Url "https://newtenant.com" -HostHeaderWebApplication $web -SiteSubscription $sub -Template "sts#0" -OwnerAlias "i:05.t|adfs|[email protected]"

The user [email protected] is an account which is valid and can be used to login via ADFS (although I'm assuming this doesn't matter, because from my understanding setting -OwnerAlias should just accept anything if it's reading a SAML claim)

However, the command is failing every time due to an invalid -OwnerAlias parameter. The error I'm getting is:

New-SPSite : User cannot be found.

I can actually create the site when I use the username format DOMAIN\admin, so for some reason the cmdlet doesn't want to accept my claim unless it's a windows account.

If I create the site using the windows user format, I can then go into central admin and change the site owner to i:05.t|adfs|[email protected] without a problem.

I can even type in

$s = Get-SPSite "https://newtenant.com"
$s.Owner | fl *

And to my surprise, it does get set correctly as i:05.t|adfs|[email protected]

If I try to set the owner using Set-SPSite, I then get the error:

Set-SPSite : The specified user i:05.t|adfs|[email protected] could not be found.

Is this a bug in the SharePoint PowerShell cmdlets? Is it possible I have a setting wrong somewhere?

This is really throwing a spanner in the works as I am hoping to integrate this into a script for provisioning of new tenants.

I am using a custom claims authentication provider to provide SAML Claims resolution and validation, but even if I debug it I get no breakpoint hits when I run New-SPSite

Answer 1

try the below code and see if it works

$claim = New-SPClaimsPrincipal -TrustedIdentityTokenIssuerr $ap -Identity UserName
$site = New-SPSite $url -OwnerAlias $claim.ToEncodedString() -template "STS#0"

I think you need to encode the string to get it works. http://technet.microsoft.com/en-us/library/ff607753(v=office.14).aspx#section1

Also check this one: http://blogs.technet.com/b/speschka/archive/2013/02/03/what-you-need-to-know-about-using-ensureuser-in-claims-based-web-apps-in-sharepoint-2010-and-sharepoint-2013.aspx

Answer 2

I believe I have solved my issue.

Half of the issue was also stemming from stale PowerShell sessions, for example I'd leave my PowerShell window open during changes to my Claims Provider but changes were never reflected until I started a new PowerShell session.

This is the reason why my EnsureUser was actually showing that it was working even when it wasn't.

I managed to track the root cause to my Custom Claims Provider.

I have some built in checks to see who the current user is calling the Claims Provider, and then proceed to resolve identities based on who the current user is.

PowerShell was giving me slightly different name resolutions than when I was using my provider through a standard SharePoint site.

For Example, my current user variable was resolving to: DOMAIN\\TestUser rather than [email protected]

I have now added more checks in my claims provider to account for local logon scenarios such as via PowerShell, and confirmed this works correctly.

Answer 3

I had the same error, solved it by opening the Power shell as administrator.

Answer 4

I started by fetching the user object from the web application then use it to create the new site collection. This is what worked for me:

$wp = Get-SPWebApplication https://hostname.domaim.com
$owner = New-SPClaimsPrincipal -TrustedIdentityTokenIssuer $wp -Identity "domain\username"

New-SPSite $site -OwnerAlias $owner -HostHeaderWebApplication $wp -Name $portalName -ContentDatabase $dbname -Template $portalTemplate | Out-Null