New content will be published over there.

I do have two scripts that will clean these users up. This will be something you want to test out since this is a delete function (leave $RemoveUsers = $false).

Just a bit of information about your site…

This script does require some modification to tailor it for your environment. The service account is needed even if it's the local domain. This was designed this way, so you can use this script for sites that have users from different domains.

As stated above, $RemoveUsers is the switch to make this to script to remove the users that were not found in Active Directory. By default, this is set to $false.

After everything is set, run "GetUsers".

CSV is created.

The CSV will be created if any users are in the site collections that are no longer in Active Directory or are disabled. Review this before feeding it through the second script. There might be some accounts you may have false positives or just want to remove a few entries.

This script is more straight forward since we are taking that CSV and removing the user from the URL specified in the CSV. I would recommend backing up the content database(s) that could be affected by the this script.

DeletedADUsersFromsites1.1.ps1 can be downloaded here

The second script can be downloaded here.

I have a post about the Migration from Windows to ADFS which utilizes the creation of the -UseDefaultConfiguration switch. A few days ago, I created a Trusted Identity Provider with -UseDefaultConfiguration. I did not need it in my test farm anymore, so it was time to delete it.

This failed with this exception:

PS C:\windows\system32> Remove-SPTrustedIdentityTokenIssuer foo

Remove-SPTrustedIdentityTokenIssuer : The trusted login provider is in use and cannot be deleted.

At line:1 char:1

+ Remove-SPTrustedIdentityTokenIssuer foo

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo : InvalidData: (Microsoft.Share...dentityProvider:SPCmdletRemoveSPIdentityProvider) [Remove-SPTrustedIdentityTok

enIssuer], InvalidOperationException

+ FullyQualifiedErrorId : Microsoft.SharePoint.PowerShell.SPCmdletRemoveSPIdentityProvider

Only Two Checks

There are only two reasons this exception is tossed when trying to remove the Trusted Identity Token Issuer.

1. Use in the web application authentication providers
2. Claim Provider with the same name as your Trusted Identity Token Issuer

The first is the obvious choice to check since the Trusted Identity Token Issuer cannot be deleted if used by a web application. If you have numerous web applications with many zones to check, this can take a long time. The PowerShell script below numerates all the web applications and their zones to display the authentications that are enabled in those zones.

Example of the output:

I checked the authentication providers. I have ADFSAdamsor in use and you can see the web application URL and zone at the top. Any that would come up we would just remove the that zone from using the Trusted Identity Token Issuer.

Claim Provider

The second check for Remove-SPTrustedIdentityTokenIssuer is Claim Providers that have the same name as the Trusted Identity Token Issuer.

Get-SPClaimProvider will display all the claim providers installed on the farm.

As the screenshot above shows, I have the claim provider that was created with -UseDefaultConfiguration. I was able to remove the claim provider then removed the Trusted Identity Token Issuer.

Remove-SPClaimProvider <NAME>

Remove-SPTrustedIdentityTokenIssuer <NAME>

This will prevent the User Profile Service Application from functioning properly. ULS shows the topology.svc tossing this "The requested application could not be found" with EventID evr4.

We can try to start the by running the Provision method to get the service application Started.

$upa = Get-SPServiceApplication <GUID of Service Application>

$upa.Provision()

This did fail and in the ULS logs we found this entry.

05/26/2018 11:13:46.90    PowerShell_ISE.exe (0x4AF4)    0x48F4    SharePoint Portal Server    User Profiles    ojxm    High    SSP administration site owner is 'i:0#.w|oldaccount\deleted'.    018afcc8-f800-0001-5e35-00e1678bd301

SSP administration is a blast from the past. The reference is back to 2007 but service applications replaced the SSP in SharePoint 2010. This entry is stating we're looking for owner of the Central Admin. This value can be exposed by using PowerShell as well.

$site = Get-SPSite https://centralAdmin:1234

$site.Owner

Or the UI with Site Settings and Site Collection Administrators

Or the Change site collection administrators in Central Admin

Find that account there and replace it with a valid account then run the Provision() PowerShell.

User Profiles are Key

Group Membership in User Profiles

$site = Get-SPSite "https://adamsor-2013upa"

$userprofile = "i:05.t|adfs|user@contoso.com"

$ServiceContext = [Microsoft.SharePoint.SPServiceContext]::GetContext($site);

$pm = new-object Microsoft.Office.Server.UserProfiles.UserProfileManager($ServiceContext)

$up = $pm.GetUserProfile($userprofile)

[xml]$xml = ($up.Memberships.GetDataSet()).getxml()

$xml.SelectNodes("//Title")

GroupClaimType

There is another way….

Different Users, Different Permissions

What's the difference?

• User Profiles
• My Sites
• Permissions(users will report random access denied)
• Alerts
• Personal Views

The Best Practice

1. We don't want to use or trust the My Site Cleanup job.
2. We have a batch of stub user profiles that need to be deleted.
3. We just want to delete some user profiles for testing purposes.
4. We don't want to wait 30 days before the User Profile is deleted by the My Site Cleanup timer job(applies only to SharePoint 2016)

NOTE: Deleting user profiles with this script will delete just the user profile.  This will not delete their My Site or send out that notification like the My Site cleanup job. WARNING: This script will delete user profiles specified in the file. The only other means to recover the user profile is to restore the Profile DB from backup.

The List

There are a few ways that we can gather a list of user profiles. We can query the profile database, run GetNonImportedObjects, or we already have a list that we want to delete.

1. Profile DB query - Select NtName from UserProfile_Full with(nolock) where bdeleted=1
2. PowerShell

   $upa = Get-spserviceapplication | ?{$_.typename -match "profile"}

Set-SPProfileServiceApplication $upa -GetNonImportedObjects $true | out-file c:\temp\NonImportedProfiles.txt

We just want the list to be a text file with the a NTName on each line.

Parameters

We will just need to modify the top 3 lines to adjust it for our farm. The first is $siteurl. This should be URL that is consuming from the User Profile Service Application. The $file is the location and name of the input file we created above. The $log is for the location of the log file(Yes, there is logging with my PowerShell scripts). Just make sure the directory is created.

One gotcha is to make sure the account running this script has permissions to the User Profile service application. This can be accomplished in Central Admin with adding the account into Permissions with Full Control.

Link to the Script

Why should we do this?

The account name for user profiles are important and what is used to get the profile. Windows Authentication user profiles are just "domain\username" for the account name. When SAML or FBA users invoke the user profiles, the profile service will search for the complete claim(example: "i:05.t|adfs30|User1"). If the user profile is not there, a stub profile will be created. This will give the user two profiles. The main one with SAML/FBA will NOT be sync'd since we would need configure MIM know the claim prefix.

1.       Open MIM client then Metaverse Designer.  Select "person" then "Add Attribute".

New Attribute button.

Type in "SPS-ClaimID" for Attribute Name

Click OK

2. Open the ADMA then Configure Attribute Flow. Select user/person

a.       Map your Claim identifier for your SAML users to SPS-ClaimID.  The direction should be Import and Direct.

b.       Click "New".

Find SPS-ClaimProviderType and SPS-ClaimProviderID in MetaVerse object type.  Below is PowerShell to find your SAML Identity Claim.

Select "Advanced" for "Mapping type" and "Import" for Direction.  Click New. 

The constant value SPS-ClaimProviderID will be the name of your SAML provider when you created it. 

SPS-ClaimProviderType will be "Trusted" if you're using a Trusted provider.

3.       Open SharePoint MA(SPMA). Click on Select Attributes.  Check the box for SPS-ClaimID.

4.      Configure Attribute Flow. Select user/person.

a.       Map SPS-ClaimID to SPS-ClaimID.  The direction will be export and Direct.  Click new. 

I'm using UPN for my environment.  This will be the identifier claim which could be email or samaccountname(see above for PowerShell).

5.       Run a full sync

1. The SharePoint farm has to be at June 2014 CU (or higher) for SharePoint 2013(15.0.4623.1001).
2. The web applications must be Windows Claims. SAML is not supported on classic.
3. ADFS must be backed with the same Active Directory used in Windows Claims.

Steps to be completed:

1. Configure ADFS
2. Creating Trusted Identity Provider
3. Migrate Users and Groups

Config ADFS

1. In AD FS, right click Relying Party Trusts and select Add Relying Party Trust.
   
2. This will bring up Add Relying Party Trust Wizard. Click Start
   
3. Click Enter data about the relying party manually, Next.
   
4. Type in a display name and description(optional). Click Next.
   
5. We want to select AD FS 1.0 and 1.1 profile since SharePoint does not support anything but SAML 1.1.
   
6. We will need to enter in the web application with /_trust. This will need to be HTTPS.
   
7. We will need to add in the realm for an identifier. I entered in urn:sp13:contoso. We will be using this on the SharePoint side.
   
8. I'm not using Multi-factor so just clicking Next
   
9. We're permitting everybody through. Click Next
   
10. Click Next
    
11. Click Close and leave the box checked. We will be mapping claims.
    
12. In the Issuance Transform Rules, click Add Rule…
    
13. Leave the drop down value at Send LDAP Attributes as Claims. Click Next
    
14. Give the claim rule a name. Select Active Directory from the dropdown.
    
15. We will only be mapping the required fields here. The first one we will map is your identifier claim. This is the claim that a user needs to have in AD to sign in. The only choices Account-Name, Email or USER-PRINCIPAL-NAME. Adjust your guide as needed. I will be using Email. The only other Claim is for security groups.
    

1. We will need the Token-sign certificate from ADFS. Click on Certificates, then click on the token-signing certificate, then View Certificate
   
2. Click on Details tab and Copy to File…
   
3. DER .CER is the file format we want. Click Next
   
4. Give the file a name and location. Click Next
   
5. Click Finish. Copy the certificate to the SharePoint server.
   

Creating Trusted Identity Provider

1. On the SharePoint server, open PowerShell ISE. We will be loading the SharePoint module using Add-PSSnapin *sharepoint*
   
2. This is to set the path of the token signing certificate we got from ADFS

3. We want SharePoint to trust the certificate.

4. The script to create the trusted provider in SharePoint.

The -Realm is what we put in as an identifier for ADFS(urn:sp13:contoso)

The -IdentifierClaimIs can only be ACCOUNT-NAME, EMAIL, or USER-PRINCIPAL-NAME.

 We can add in more claims after the trusted provider is created. Example is below of adding a role claim.

Migrate Users and Groups

Resources

What flavor of FBA?

FBA can come in various deployments with the backend being SQL, .NET, etc. The most common being LDAP which I will be using in this post for the 8306. The deployment documents for this is in the following TechNet articles.

2013 - https://technet.microsoft.com/en-us/library/ee806890.aspx

2010 - https://technet.microsoft.com/en-us/library/ee806890(v=office.14).aspx

What Process is tossing 8306?

The error that we're chasing down can be reproduced in any environment with FBA. The text of the error states we have failed to issue a token.

This is being tossed by the web application's application pool(0x2AD0) but really it's bubbling up from the Security Token Service.

ULS logs shows us the exception for the web app:

Here you can see the failure happen earlier in the request(filter by correlationID) in the STS:

With this information we need to take a Network trace from the WFE since it's making the request to the DC(Domain Controller). I use a tool called Netmon 3.4 We can check the web.config of the STS to see where we are pointing to verifying the username and password.

LDAP is used over ports 386 and 636(SSL). Netmon has standard filters that can be applied.

Netmon on the WFE:

The Netmon here show that we're not getting any response from the DC which is one example of this error. Others may manifest itself as different issues all together.

Root Cause?

The ULS logs usually just says it failed while trying to validate the Username and Password.

12/23/2017 16:09:35.77    w3wp.exe (0x5A80)    0x92C0    SharePoint Foundation    Claims Authentication    fo1t    Monitorable    STS Call: Failed to issue new security token. Exception: System.ServiceModel.FaultException`1[Microsoft.IdentityModel.Tokens.FailedAuthenticationException]: The security token username and password could not be validated. (Fault Detail is equal to Microsoft.IdentityModel.Tokens.FailedAuthenticationException: The security token username and password could not be validated.).    7580399e-8900-708b-67e2-ab7bcf6013a3

Here are the most common reasons you'll see 8306 in your FBA deployment:

1. Somebody put in the wrong username and password
2. Communication with the DC(in my example above I had a firewall block LDAP traffic)
3. Misconfiguration of the web.configs

The first reason is odd one, but it's true. Putting in incorrect credentials will toss a 8306 with the same text as above (The user name and password is not validated.). If you're seeing inconsistent results, you might have a DC that isn't responding correctly which the Netmon will be valuable to isolate the issue to one WFE or DC that is affected.