How to add a user to Web Application User Policy using PowerShell

To add a user to web application user policy using PowerShell , use the below PowerShell script

$userOrGroup = "i:0#.w|domain\user"

$displayName = "User-NTLM"

$webApp = Get-SPWebApplication("URL")

$policy = $webApp.Policies.Add($userOrGroup, $displayName)

$policyRole = $webApp.PolicyRoles.GetSpecialRole([Microsoft.SharePoint.Administration.SPPolicyRoleType]::FullControl)

$policy.PolicyRoleBindings.Add($policyRole)

$webApp.Update() 

SharePoint 2010 User Active Directory Permissions not updating

When you are using Active Directory groups and add those groups into SharePoint groups, you will run into issues while modifying the members of the Active Directory group. It takes 24 hours (by default) to reflect this change to SharePoint.This behavior is controlled by a property called Token-timeout.By default, this value is set to 1440 minutes (24 hours) .

SharePoint fetches user token information from the SharePoint database. If the user has never visited the site or if the user’s token was generated more than 24 hours previously, SharePoint generates a new user token by trying to refresh the list of groups that the user belongs to.(MSDN Reference)

To check which values you currently have, try running the below:

 stsadm –o getproperty –propertyname token-timeout

If you want to minimize this token time out value (time it takes to refresh the token), follow the below instructions.

To set a valid time to 2000 minutes, use the following syntax:

stsadm -o setproperty -pn token-timeout -pv 2000

Note: You can substitute -pn for -propertyname and -pv for -propertyvalue. 

Name	Value
propertyname	Gets or sets the name of the property.
propertyvalue	A valid time interval, in minutes. The default setting is 1440 minutes.

The syntax for the setproperty operation is:

stsadm -o setproperty -propertyname token-timeout –propertyvalue <A valid time interval, in minutes>

Note:

- This property applies to the entire farm.

- The use of stsadm will only affect the ContentService Web service property and not the AdministrationService Web service property.

Warning: If you set Token-timeout to zero (0) it can bring the farm down and you get this error message
"The context has expired and can no longer be used. Exception from HRESULT: 0x80090317"

Related

Active Directory Group Sync Issue with SharePoint 2013 Permissions

Issue

AD security group permissions are being used to control access in SharePoint 2013, however, changes to group membership in AD are not taking effect immediately in SharePoint 2013. In simple words, even after you remove a user from the AD security group - user is still able to access the site. If you add a new user to the AD security group, user still receives access denied error message in SharePoint.

Workaround - If you need to have the change take effect immediately, you can do an Application Pool recycle for that web application. 

Cause

In Windows Claims enabled web application (the default for SharePoint 2013), the logon token life time is by default 10 hours and cache life time is by default 10 minutes. Hence, the AD group modifications will not reflect immediately in SharePoint user sign-in. internally what happens is when a user accesses a SharePoint site, SharePoint checks the security token store cache for the user's claims. If the claim is found in the cache, SharePoint uses it to authorize the user. If not, SharePoint queries for claims again from the AD.

To check which values you currently have, try running the below:

$sts = Get-SPSecurityTokenServiceConfig
$sts.WindowsTokenLifetime
$sts.LogonTokenCacheExpirationWindow

Resolution

The value of token life time and cache expiration time can be set to the desired value per your needs.Lowering the token life time introduces more round trips to AD to authenticate the user, which means performance characteristics should be monitored to determine the appropriate lifetime.I have seen 10 minutes being recommended to use, but this is something that needs to be tested as it should be considered on a case by case scenario.If you would like to change the token life time, you can use the following PowerShell cmdlet to set the Windows token life time and cache expiration window to the desirable value.

The below example sets your WindowsTokenLifetime to 10minutes (10 hours is the default) and the Cache Expiration to 2 minutes (10 minutes is the default).

$sts = Get-SPSecurityTokenServiceConfig
$sts.WindowsTokenLifetime = "00:10:00"
$sts.LogonTokenCacheExpirationWindow = (New-TimeSpan –minutes 2)
$sts.Update()
iisreset 

Warning

If you set Token lifetime lesser than the token expiration window, you get this error message

"The context has expired and can no longer be used. Exception from HRESULT: 0x80090317"

Get-SPSecurityTokenServiceConfig

Set-SPSecurityTokenServiceConfig

Related

AD Groups not displayed in SharePoint People Picker

Issue description

A user had created and Active Directory group and was not able to see the group in SharePoint People Picker

SharePoint version: SharePoint 2010 SP2

Cause                                                                                                                                             

The Active Directory group was created as a Distribution group

Resolution                                                                                                                                   

Active Directory groups should be a created as Security group (not Distribution group) to get listed in SharePoint People Picker.

Distribution groups cannot be used as security instances, such as assigning permissions to them. SharePoint uses Active Directory to authenticate a user. In order to do this, it must be a security principle that SharePoint is working with. Distribution groups are not security principles. 

Configuring Replicating Directory Changes

While provisioning the User Profile Service (UPS), we can synchronize user profile information using the User Profile Synchronization Service. Synchronization between AD and SharePoint should be done using a domain account, called the synchronization account, i.e. DOMAIN\SPFarmAccount. This synchronization account requires Replicate Directory Change permissions in the domain.

Below are the steps on how you do this.

1. Open Active Directory Users and Groups with local machine Administrator permissions.

2. Right click the domain and select Delegate Control.

3. Click Next on the Delegation Control Wizard welcome page.

4. On the Users or Groups page, add the domain\account of your SharePoint farm admin account and click Next.

5. On the Tasks to delegate page, select “Create a custom task to delegate” and click Next.

6. On the Active Directory Object Type page, keep the default options and click Next.

7. On the Permissions page, check the “Replicating Directory Changes” and click Next

8. Click Finish to complete the Delegation of Control Wizard.

Zone Creation and Host Entries in ActiveDirectory

In this blog entry, I am creating a new zone in the DNS namely dev.com.

Below steps will help you in that.

1) Go to Start -> Administrative Tools ->DNS 

2) Right click on ServerName -> New Zone

3) The New Zone wizard opens and click Next.

4) Select Primary zone and click Next.

5) Select To all DNS servers running on domain controllers in this domain : DEV.NET and click Next.

6) Create a Forward lookup zone and click Next.

7) Give the zone name as dev.com. Click Next.

8) Select Allow only secure dynamic updates and click Next.

9) Click Finish on zone creation completion.

10) Creation of a new host is the next step.Right click on the newly created zone and select New Host(A or AAAA).

11) Enter the Host name and IP address and click Add Host.

12) Host creation successful message is shown.

13) I am creating 4 host records with same IP address 

a)    collaboration

b)    social

c)    community

d)    partner

14) The following screen shows the four host records.