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|admin@newtenant.com"

The user admin@newtenant.com 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|admin@newtenant.com 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|admin@newtenant.com

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

Set-SPSite : The specified user i:05.t|adfs|admin@newtenant.com 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


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

  • I've given that a shot but unfortunately I get the same error, I also tried running $web.EnsureUser("i:05.t|adfs|admin@newtenant.com") and I do get a result back, it does not throw me an exception – Antix Jul 12 '14 at 8:33

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 testuser@domain.com

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.

  • Yeah, mine was resolved with the funky claims resolution mentioned, so "i:0#.w|Domain\username" – cluckinchicken Oct 18 '18 at 13:39

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.