Claims to windows token service что это

title	description	ms.date	ms.prod	ms.assetid	ms.localizationpriority
Claims-based identity and concepts in SharePoint	Article with links to learn about the claims-based identity model and concepts in SharePoint.	06/07/2022	sharepoint	d96c7cf4-2e48-4223-a3c0-42368d079b74	medium

Claims-based identity and concepts in SharePoint

Claims-based identity model

When you build claims-aware applications, the user presents an identity to your application as a set of claims. One claim could be the user’s name, another might be an email address. The idea here is that an external identity system is configured to give your application all the information it needs about the user with each request, along with cryptographic assurance that the identity data received by your application comes from a trusted source.

Under this model, single sign-on is much easier to achieve, and your application is no longer responsible for the following:

• Authenticating users

• Storing user accounts and passwords

• Calling to enterprise directories to look up user identity details

• Integrating with identity systems from other platforms or companies

Under this model, your application makes identity-related decisions based on claims supplied by the user. This could be anything from simple application personalization with the user’s first name, to authorizing the user to access higher value features and resources in your application.

The following sections introduce terminology and concepts to help you understand the claims-based identity architecture.

Identity: A set of attributes that describe an entity

Identity is a set of attributes that describe a user, or some other entity, in a system that you want to secure.

Claim: A piece of identity information

Think of a claim as a piece of identity information (for example, name, email address, age, or membership in the Sales role). The more claims your application receives, the more you know about your user. These are called «claims» rather than «attributes,» as is commonly used in describing enterprise directories, because of the delivery method. In this model, your application does not look up user attributes in a directory. Instead, the user delivers claims to your application, and your application examines them. Each claim is made by an issuer, and you trust the claim only as much as you trust the issuer. For example, you trust a claim made by your company’s domain controller more than you trust a claim made by the user.

Security token: A serialized set of claims

The user delivers a set of claims to your application with a request. In a web service, these claims are carried in the security header of the SOAP envelope. In a browser-based web application, the claims arrive through an HTTP POST from the user’s browser, and may later be cached in a cookie if a session is desired. Regardless of how these claims arrive, they must be serialized. A security token is a serialized set of claims that is digitally signed by the issuing authority. The signature is important: it gives you assurance that the user did not just make up claims and send them to you. In low-security situations where cryptography is not necessary or desired, you can use unsigned tokens, but that scenario is not described in this article.

One of the core features in Windows Identity Foundation (WIF) is the ability to create and read security tokens. WIF and the Microsoft .NET Framework handle all of the cryptographic work, and present your application with a set of claims that it can read.

Security token service (STS)

A security token service (STS) is the plumbing that builds, signs, and issues security tokens according to the interoperable protocols discussed in the «Standards» section of this article. There is a lot of work that goes into implementing these protocols, but WIF does all of this work for you, making it possible for someone who is not a protocols expert to get an STS up and running with little effort.

WIF makes it easier to build your own STS. It is up to you to figure out how to implement the logic, or rules, that enforce it (often referred to as security policy).

Issuing authority

There are many different types of issuing authorities, from domain controllers that issue Kerberos tickets, to certificate authorities that issue X.509 certificates. The specific type of authority discussed in this article issues security tokens that contain claims. This issuing authority is a web application or web service that issues security tokens. It must be able to issue the proper claims given the target relying party and the user making the request, and might be responsible for interacting with user stores to look up claims and authenticate users.

Whatever issuing authority you choose, it plays a central role in your identity solution. When you factor authentication out of your application by relying on claims, you are passing responsibility to that authority and asking it to authenticate users on your behalf.

Relying parties

When you build an application that relies on claims, you are building a relying party application. Synonyms for a relying party include «claims-aware application» and «claims-based application». Web applications and web services can both be relying parties.

A relying party application consumes tokens issued by an STS and extracts claims from tokens to use them for identity related tasks. The STS supports two types of relying party application: ASP.NET web applications, and Windows Communication Foundation (WCF) web services.

Standards

To make all of this interoperable, several WS-* standards are used in the previous scenario. Policy is retrieved by using WS-MetadataExchange, and the policy itself is structured according to the WS-Policy specification. The STS exposes endpoints that implement the WS-Trust specification, which describes how to request and receive security tokens. Most security token services today issue tokens formatted with Security Assertion Markup Language (SAML). SAML is an industry-recognized XML vocabulary that can be used to represent claims in an interoperable way. Or, in a multiplatform situation, this enables you to communicate with an STS on an entirely different platform and achieve single sign-on across all of your applications, regardless of platform.

Browser-based applications

Smart clients are not the only ones who can use the claims-based identity model. Browser-based applications (also referred to as passive clients) can also use it. The following scenario describes how this works.

First, the user points a browser at a claims-aware web application (the relying party application). The web application redirects the browser to the STS so that the user can be authenticated. The STS is hosted in a simple web application that reads the incoming request, authenticates the user by using standard HTTP mechanisms, and then creates a SAML token and replies with a piece of ECMAScript (JavaScript, JScript) code that causes the browser to initiate an HTTP POST that sends the SAML token back to the relying party. The body of this POST contains the claims that the relying party requested. At this point, it is common for the relying party to package the claims into a cookie so that the user does not have to be redirected for each request.

Claims to Windows Token Service (c2WTS)

The Claims to Windows Token Service (c2WTS) is a feature of Windows Identity Foundation (WIF). The c2WTS extracts user principal name (UPN) claims from non-Windows security tokens, such as SAML and X.509 tokens, and generates impersonation-level Windows security tokens. This allows a relying party application to impersonate the user. This might be needed to access back-end resources, such as Microsoft SQL Servers, that are external to the computer running the relying party application.

The c2WTS is a Windows service that is installed as part of WIF. For security reasons, the c2WTS works only on an opt-in basis. It must be started manually and it runs as the local system account. An administrator must also manually configure the c2WTS with a list of allowed callers. By default, the list is empty.

If your relying party application runs as the local system account, it does not need to use the c2WTS. But, if your relying party application runs as the network service account, or is an ASP.NET application, for example, it might need to use the c2WTS to access resources on another computer.

Suppose that you have a web farm that consists of a server that runs an ASP.NET application, which accesses a SQL database on a back-end server. You want to make this application claims-aware. But, the application can’t access the SQL database by using the claim that it receives from an STS. Instead, it uses the c2WTS to convert the UPN claim to a Windows security token. This allows it to access the SQL database.

[!NOTE]
To allow an application to access resources on a different server, a domain administrator must configure the Active Directory directory service to enable constrained delegation. For information about how to enable constrained delegation, see How to: Use protocol transition and constrained eelegation in ASP.NET 2.0.

See also

• Authentication, authorization, and security in SharePoint

• Sample delegation, federation, and authentication scenario in SharePoint

• Claims-based identity term definitions

Posted On December 30, 2018

Update: 3/31/22 — Added a reference to a related post from my colleague Mike: Unable to start the C2WTS

Update: 8/5/19 — Made an amendment to Fact #3.

Facts:

1. The Claims to Windows Token Service (from here on denoted as “C2WTS”) is only used when SharePoint needs to get data from an external system that does not understand claims.  Examples of features that can be configured to use C2WTS include, but are not limited to:

• SQL Server Reporting Services (SSRS)
• Excel Web Services (EWS)
• PowerPivot / Power View
• Business Data Connectivity (BDC) / Business Connectivity Services (BCS) / External Content Types (ECT) / External Lists.
• Other SharePoint “BI” stuff.
• Custom Code that does user impersonation.

Normal SharePoint stuff (browsing sites, working in native lists / libraries, etc) does not use the C2WTS.

— I’ve seen many cases where we’ve spent a lot of time configuring the C2WTS to try to fix some authentication or permissions issue, when in fact, the C2WTS doesn’t even come into play in those scenarios.

2. The C2WTS can only be accessed on the local server, so when you are using it, the service must be running on all of your WFEs and any other server that will access the external data.

3. Out of the box, it only works for Windows-Claims web apps.  It does not work for Trusted Provider / SAML claims (ADFS, Ping, SiteMinder, etc).  Even if you pass UPN as one of your claims, it will not work**.

See this: https://technet.microsoft.com/en-us/library/ee806870.aspx#section2

Excerpt: “It is important to understand that these service applications can use the C2WTS only if the incoming authentication method is either Windows claims or Windows classic mode. Service applications that are accessed through web applications and that use Security Assertion Markup Language (SAML) claims or forms-based authentication claims do not use the C2WTS. Therefore, they cannot translate claims to Windows credentials.”

** I found that certain custom claim providers may also contain the custom code necessary to make C2WTS work with their SAML claims. For example, the Okta farm-level solution contains such code. In that case, you must be passing UPN as one of the claims, and you must have custom farm-level property “MapUpnToWindowsUser” set. Reference.

4. This is not necessarily an “error”:

11/09/2017 17:55:14.15 w3wp.exe (0x1A88) 0x2978 SharePoint Foundation Claims Authentication bz7l Medium SPSecurityContext: Could not retrieve a valid windows identity for username ‘CONTOSOUser1’ with UPN ‘User1@contoso.com’. UPN is required when Kerberos constrained delegation is used. Exception: System.ServiceModel.FaultException`1[System.ServiceModel.ExceptionDetail]: WTS0003: The caller is not authorized to access the service. (Fault Detail is equal to An ExceptionDetail, likely created by IncludeExceptionDetailInFaults=true, whose value is: System.UnauthorizedAccessException: WTS0003: The caller is not authorized to access the service.

at Microsoft.IdentityModel.WindowsTokenService.CallerSecurity.CheckCaller(WindowsIdentity callerIdentity)

at Microsoft.IdentityModel.WindowsTokenService.S4UServiceContract.PerformLogon(Func`1 logonOperation, Int32 pid)

at SyncInvokeUpnLogon(Object , Object[] , Object[] )

at System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke(Object instance, Object[] inputs, Object[]& outputs)

at System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin(MessageRpc& rpc)

at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(MessageRpc& rpc)

at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage11(MessageRpc& rpc)

at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet))..

Many times we see the above in the SharePoint ULS logs because there is some custom code in the master page or in a web part that calls an “impersonate” method, which results in calling into the Claims to Windows Token Service (C2WTS).  But C2WTS may not be required for that code to work, so even though it throws the above error, it causes no actual problem.

Before digging into this “error”, you must ask yourself: “Does what I’m troubleshooting even use the C2WTS?” (see Fact #1 above).

Proper Permission Configuration:

Most C2WTS issues I see are a problem with configuring the service, more specifically with properly configuring permissions for the account that runs it.

Here’s a summary of how you should configure it:

Permissions Check list:
Reference here: https://technet.microsoft.com/en-us/library/hh231678(v=sql.110).aspx

Note: The end-to-end configuration for C2WTS will include setting up delegation on the C2WTS account.  These steps vary depending on what you’re trying to get C2WTS to pull data from, and therefore are beyond the scope of this post.  However, here’s an example of setting it up for SSRS.

• For Users calling the service

By “calling the service”, I mean any user browsing the SharePoint page, web part, SSRS report, Excel spreadsheet, etc that connects to some back-end service that utilizes the C2WTS. These users directly call the service and need permission to do so.
Edit c2wtshost.exe.config at C:Program FilesWindows Identity Foundationv3.5 and make sure all users have access to call the service.  — Adding “NT AUTHORITYAuthenticated Users” to the allowed callers list ought to take care of that.

<allowedCallers>
<clear/>
<add value=”NT AUTHORITYNetwork Service” />
<add value=”NT AUTHORITYLocal Service” />
<add value=”NT AUTHORITYSystem” />
<add value=”NT AUTHORITYAuthenticated Users” />
</allowedCallers>

• For the account running the C2WTS service (in services.msc):

• On the SharePoint boxes running C2WTS:

  • Add to the local Administrators group

  • Add to the local security policy (Start > Administrative Tools > Local Security Policy > Local Policies > User Rights Assignment),

    • Act as part of the operating system
    • Impersonate a client after authentication

    • Log on as a service

• On the domain(s):

  • Needs to have the “Read tokenGroupsGlobalAndUniversal” permission to all the users in the domain.

    • To give this permission, we need to add it to the “Windows Authorization Access Group” builtin domain group, which should have this permission to all domain accounts by default.
    • The account needs these permissions on every domain that contains the users that are calling the service.  So if you have a number of domain / forest trusts, and users from these other domains are browsing your SharePoint sites and using stuff that invokes the C2WTS, then you need to add your C2WTS service account to the “Windows Authorization Access Group” in every one of those domains.

Other notes for configuring C2WTS:

This service can only be accessed locally, so it needs to be running on all the machines in the farm that require it.  For example, in the case of SSRS, it needs to be running on the servers running the SSRS service.  Because it may not immediately be clear where you need the service in each scenario, you may choose to just run it on all servers in the farm.

Keep in mind that the c2wtshost.exe.config file edit, and the local security policy changes listed above need to be made on every server running C2WTS.

If you stop the C2WTS and start it again in Central Administration | Manage Services on Server, that will cause the c2wtshost.exe.config file to revert to its out-of-box version, and your users won’t be allowed access anymore. If you want to restart the service, just restart the Windows service within services.msc:

Important: If the Claims to Windows Token Service won’t start at all, you may have a problem within the c2wtshost.exe.config file. See this post from my colleague Mike Lee: Unable to start the C2WTS

Troubleshooting:

If you have configured permissions properly as described above but are still getting C2WTS errors, you can use the C2WTS tester tool:
https://rodneyviana.com/troubleshooting-claims-to-windows-nt-token-service-c2wts-in-sharepoint-2010-may-be-difficult-if-you-dont-know-where-to-start/

It’s called “c2WTSTest.zip” and you can download it here:

https://github.com/rodneyviana/blogdemos/blob/master/c2WTSTest.zip

— Here’s what the C2WTS tester tool looks like:
-By default, the tool runs as the logged-on user, but you can run it as another user by simply supplying a user name and password.
Note: This account is the user calling the service, which is different from account running the service.
-You also specify the UPN to try to convert to a Windows token.  This can be the UPN for the user running the tool, or some other UPN altogether.
-Here’s what a successful run of the tool looks like:

— As you can see, it checks that the caller has permission per the “allowedCallers” tag in the c2wtshost.exe.config file, that the user can log in, and that the service account has permission to create the Windows token.

— And here’s an example of a failure:

Error Text:
***** c2WTS could not provide a valid Windows Token. Reason: Access is denied.

Server stack trace:
at System.ServiceModel.Channels.ServiceChannel.ThrowIfFaultUnderstood(Message reply, MessageFault fault, String action, MessageVersion version, FaultConverter faultConverter)
at System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc)
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at Microsoft.IdentityModel.WindowsTokenService.S4UClient.IS4UService_dup.UpnLogon(String upn, Int32 pid)
at Microsoft.IdentityModel.WindowsTokenService.S4UClient.<>c__DisplayClass1.<UpnLogon>b__0(IS4UService_dup channel)
at Microsoft.IdentityModel.WindowsTokenService.S4UClient.CallService(Func`2 contractOperation)
at c2WTSTest.Form1.button2_Click(Object sender, EventArgs e)

— It can be useful to take a Netmon (Network Monitor 3.4) trace while running the tester tool.
-The C2WTS uses Kerberos calls, so if you filter like tcp.port == 88, then you will see the request.

Here’s an example of a failing sequence:

— We can see it fails with “KDC_ERR_C_PRINCIPAL_UNKNOWN” which means “Client not found in Kerberos database”.  The “client” in this case is the user we tried to generate a token for.

— See: http://support.microsoft.com/kb/2009157

As specified above, the service account running the C2WTS needs to have the “Read tokenGroupsGlobalAndUniversal” permission to all the users in the domain (or at least all users that want to be able to invoke it and render their favorite SSRS reports, or whatever you’re using C2WTS for).

To give this permission, we need to add it to the “Windows Authorization Access Group” builtin domain group.
By default, the “Windows Authorization Access Group” has the “Read tokenGroupsGlobalAndUniversal” permission to all accounts in the domain.  If that has been removed for some reason, we’ll need to add it or the equivalent permissions back. One way to check permissions in AD is to go to Active Directory Users and Computers | Properties for a user | Security | Advanced | Effective Access.  Choose the C2WTS service account and make sure it has (at least) the “Read tokenGroupsGlobalAndUniversal” permission.

Here’s an example where my service account (m1garandservice) does not have the correct permission to the User1 user account:

— In this case, I reproduced this behavior with an explicit deny on the Read tokenGroupsGlobalandUniversal permission for the User1 account, but out in the wild, you’d likely see this because the C2WTS service account is not in the “Windows Authorization Access Group” for all applicable domains. Have I mentioned that’s an important permission yet?

Full SharePoint ULS log example for the Access Denied error:

SPSecurityContext.WindowsIdentity: Could not retrieve a valid windows identity for NTName=’CONTOSOUser1′, UPN=’user1@contoso.com’. UPN is required when Kerberos constrained delegation is used. Exception: System.ServiceModel.Security.SecurityAccessDeniedException: Access is denied.
Server stack trace:
at System.ServiceModel.Channels.ServiceChannel.ThrowIfFaultUnderstood(Message reply, MessageFault fault, String action, MessageVersion version, FaultConverter faultConverter)
at System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc)
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)
Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at Microsoft.IdentityModel.WindowsTokenService.S4UClient.IS4UService_dup.UpnLogon(String upn, Int32 pid)
at Microsoft.IdentityModel.WindowsTokenService.S4UClient.<>c__DisplayClass1.<UpnLogon>b__0(IS4UService_dup channel)
at Microsoft.IdentityModel.WindowsTokenService.S4UClient.CallService(Func`2 contractOperation)
at Microsoft.SharePoint.SPSecurityContext.GetWindowsIdentity().Throwing Microsoft.ReportingServices.Diagnostics.Utilities.ClaimsToWindowsTokenException: , Microsoft.ReportingServices.Diagnostics.Utilities.ClaimsToWindowsTokenException: Cannot convert claims identity to windows token. —> System.InvalidOperationException: Could not retrieve a valid Windows identity. —> System.ServiceModel.Security.SecurityAccessDeniedException: Access is denied.
Server stack trace:
at System.ServiceModel.Channels.ServiceChannel.ThrowIfFaultUnderstood(Message reply, MessageFault fault, String action, MessageVersion version, FaultConverter faultConverter)
at System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc)
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)
Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at Microsoft.IdentityModel.WindowsTokenService.S4UClient.IS4UService_dup.UpnLogon(String upn, Int32 pid)
at Microsoft.IdentityModel.WindowsTokenService.S4UClient.<>c__DisplayClass1.<UpnLogon>b__0(IS4UService_dup channel)
at Microsoft.IdentityModel.WindowsTokenService.S4UClient.CallService(Func`2 contractOperation)
at Microsoft.SharePoint.SPSecurityContext.GetWindowsIdentity()
— End of inner exception stack trace —
at Microsoft.SharePoint.SPSecurityContext.GetWindowsIdentity()
at Microsoft.ReportingServices.ServiceRuntime.WcfUserContext.GetWindowsIdentity()
— End of inner exception stack trace —;

Symptoms

Consider the following scenario:

You are running Microsoft SharePoint Server 2010 together with Windows Server 2008 or with Windows Server 2008 R2 on a computer that is not connected to the Internet.

After you apply the update that is described in Microsoft Knowledge Base article 2677070 to Windows Server 2008 or Windows Server 2008 R2, you restart the server.

In this scenario, the following services may not start on the SharePoint server immediately after you restart the server:

SharePoint 2010 Administration Service

Claims To Windows Token service (C2WTS)

Additionally, the following errors are logged in Event Viewer on the SharePoint server:

Error starting SharePoint 2010 Administration Service: Error: 1053: The service did not respond to the start or control request in a timely fashion.

Event ID 7009: A timeout was reached (30000 milliseconds) while waiting for the SharePoint 2010 Administration service to connect

You encounter similar error messages when you try to start the Claims To Windows Token service (C2WTS).

Cause

This issue occurs because of an inability to retrieve trusted and untrusted certificate trust lists (CTLs). If the system does not have access to Windows Update, either because the system is not connected to the Internet or because Windows Update is blocked by firewall rules, the network retrieval times out before the service can continue its startup procedure. In some cases, this network retrieval time-out may exceed the service startup time-out of 30 seconds. If a service cannot report that startup completed after 30 seconds, the service control manager (SCM) stops the service.

The URLs to update the CTL changed with this update. Therefore, if previous URLs were hard-coded as exceptions in the firewall or proxy, or if there is no Internet access on the computer, the CTL cannot be updated.

To download the latest CTLs, use the following updated URLs:

For more information about the issue, click the following article number to view the article in the Microsoft Knowledge Base:

Resolution

To work around this problem, configure the computer so that the network does not retrieve trusted and untrusted CTLs. To do this, use one of the following methods:

Validate that boundary firewalls, router access rules, and downstream proxy servers enable systems that have update 2677070 installed to contact Microsoft Update. For more information about this requirement, see the following article in the Microsoft Knowledge Base. (This includes the URLs that the CTL update accesses.)

2677070 An automatic updater of revoked certificates is available for Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2

Change the Group Policy settings. To do this, follow these steps:

Under the Computer Configuration node in the Local Group Policy Editor, double-click Policies.

Double-click Windows Settings, double-click Security Settings, and then double-click Public Key Policies.

In the details pane, double-click Certificate Path Validation Settings.

Click the Network Retrieval tab, click to select the Define these policy settings check box, and then click to clear the Automatically update certificates in the Microsoft Root Certificate Program (recommended) check box.

Click OK, and then close the Local Group Policy Editor.

Modify the registry. To do this, follow these steps.

Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:

322756 How to back up and restore the registry in Windows

Click Start, click Run, type regedit in the Open box, and then click OK.

Locate and then select the following registry subkey:
HKLMSoftwarePoliciesMicrosoftSystemCertificates

Right-click AuthRoot, select New, and then click DWORD.

Type DisableRootAutoUpdate, and then press Enter.

Right-click DisableRootAutoUpdate, and then click Modify.

In the Value data box, type 1, and then click OK.

Exit Registry Editor, and then restart the computer.

Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:

322756 How to back up and restore the registry in Windows

Click Start, click Run, type regedit in the Open box, and then click OK.

Locate and then select the following registry subkey:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControl

Right-click Control, point to New, and then click DWORD Value.

In the New Value box, type ServicesPipeTimeout, and then press Enter.

Right-click ServicesPipeTimeout, and then click Modify.

Click Decimal, type the number of milliseconds that you want to wait until the service times out, and then click OK.

For example, if you want to wait 60 seconds before the service times out, type 60000.

Exit Registry Editor, and then restart the computer.

More Information

For more information about the Windows root certificate program, certificates, certificate trust, and the certificate trust list, see the «More Information» section of the following article in the Microsoft Knowledge Base:

2677070 An automatic updater of revoked certificates is available for Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2

Источник

Symptoms

Consider the following scenario:

You are running Microsoft SharePoint Server 2010 together with Windows Server 2008 or with Windows Server 2008 R2 on a computer that is not connected to the Internet.

After you apply the update that is described in Microsoft Knowledge Base article 2677070 to Windows Server 2008 or Windows Server 2008 R2, you restart the server.

In this scenario, the following services may not start on the SharePoint server immediately after you restart the server:

SharePoint 2010 Administration Service

Claims To Windows Token service (C2WTS)

Additionally, the following errors are logged in Event Viewer on the SharePoint server:

Error starting SharePoint 2010 Administration Service: Error: 1053: The service did not respond to the start or control request in a timely fashion.

Event ID 7009: A timeout was reached (30000 milliseconds) while waiting for the SharePoint 2010 Administration service to connect

You encounter similar error messages when you try to start the Claims To Windows Token service (C2WTS).

Cause

This issue occurs because of an inability to retrieve trusted and untrusted certificate trust lists (CTLs). If the system does not have access to Windows Update, either because the system is not connected to the Internet or because Windows Update is blocked by firewall rules, the network retrieval times out before the service can continue its startup procedure. In some cases, this network retrieval time-out may exceed the service startup time-out of 30 seconds. If a service cannot report that startup completed after 30 seconds, the service control manager (SCM) stops the service.

The URLs to update the CTL changed with this update. Therefore, if previous URLs were hard-coded as exceptions in the firewall or proxy, or if there is no Internet access on the computer, the CTL cannot be updated.

To download the latest CTLs, use the following updated URLs:

For more information about the issue, click the following article number to view the article in the Microsoft Knowledge Base:

Resolution

To work around this problem, configure the computer so that the network does not retrieve trusted and untrusted CTLs. To do this, use one of the following methods:

Validate that boundary firewalls, router access rules, and downstream proxy servers enable systems that have update 2677070 installed to contact Microsoft Update. For more information about this requirement, see the following article in the Microsoft Knowledge Base. (This includes the URLs that the CTL update accesses.)

2677070 An automatic updater of revoked certificates is available for Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2

Change the Group Policy settings. To do this, follow these steps:

Under the Computer Configuration node in the Local Group Policy Editor, double-click Policies.

Double-click Windows Settings, double-click Security Settings, and then double-click Public Key Policies.

In the details pane, double-click Certificate Path Validation Settings.

Click the Network Retrieval tab, click to select the Define these policy settings check box, and then click to clear the Automatically update certificates in the Microsoft Root Certificate Program (recommended) check box.

Click OK, and then close the Local Group Policy Editor.

Modify the registry. To do this, follow these steps.

Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:

322756 How to back up and restore the registry in Windows

Click Start, click Run, type regedit in the Open box, and then click OK.

Locate and then select the following registry subkey:
HKLMSoftwarePoliciesMicrosoftSystemCertificates

Right-click AuthRoot, select New, and then click DWORD.

Type DisableRootAutoUpdate, and then press Enter.

Right-click DisableRootAutoUpdate, and then click Modify.

In the Value data box, type 1, and then click OK.

Exit Registry Editor, and then restart the computer.

Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:

322756 How to back up and restore the registry in Windows

Click Start, click Run, type regedit in the Open box, and then click OK.

Locate and then select the following registry subkey:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControl

Right-click Control, point to New, and then click DWORD Value.

In the New Value box, type ServicesPipeTimeout, and then press Enter.

Right-click ServicesPipeTimeout, and then click Modify.

Click Decimal, type the number of milliseconds that you want to wait until the service times out, and then click OK.

For example, if you want to wait 60 seconds before the service times out, type 60000.

Exit Registry Editor, and then restart the computer.

More Information

For more information about the Windows root certificate program, certificates, certificate trust, and the certificate trust list, see the «More Information» section of the following article in the Microsoft Knowledge Base:

2677070 An automatic updater of revoked certificates is available for Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2

Источник

Claims to windows token service

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

I have configured a web part in SharePoint 2010. The environment consists of 1 WFE, 1 APP, 1 SQL, 1 AS server all on Windows Server 2008 R2 Sp1 OS. I have configured C2WTS. The user domainfarmaccountuser is also part of WSS_WPG group but i still get the following error:

Answers

Initially C2WTS config file allowed callers had only 1 entry of WSS_WPG. In this case C2WTS was actually not working although c2WTSTest.exe mentioned it would work.

To make C2WTS work i made two changes:

1. Changes to C2WTS config file:

Above shows that i added Authenticated Users

2. Added NT AuthoritySystem to local WSS_WPG group

The above was tough to figure out since i felt that this should have been done automatically by the service.

————————
This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

Yes farmaccountuser is local admin.

C2WTS domain account is also local admin. I followed the Kerberos guide step by step.

Does the C2WTS user also have the following rights on the server:

Act as part of the operating system

Impersonate a client after authentication

Logon as a service

————————
This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

Yes did do those as well.

Just to be exact, i have followed all the steps detailed in the article at:

The event viewer shows me following error message:

The source was not found, but some or all event logs could not be searched. Inaccessible logs: Security.

Silly question, but after adding it to the Local Admins group, did you force the account to log off of the system?

Have you modified, either via GPO or manually the SDDL of the Security Event Log?

————————
This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

Trevor, no problem i dont mind being elaborate.

I logged in using FarmAccountUser who was already local admin on the server(WFE and AppServer). While logged on as FarmAccountUser i configured C2WTS, also added the C2WTSSvcAccount to Local Admin and then logged off. Later logged on as FarmAccountUser which didnt help. Then finally restarted both WFE and AppServer. From CA i changed the service account C2WTS service from Local System to C2WTSSvcAccount. C2WTS is configured on both WFE and AppServer, although i understand it shouldnt run on WFE. But if i stop the server on WFE the error doubles up. I get below error in addition to the earlier error that I posted. Hence i had to start C2WTS on WFE as well.

I ran c2WTSTest.exe to check if C2WTS is configured properly. I get below message when i run the tool, which indicates that the service is running properly i guess.

Services running on the servers are as follows:

Источник

Claims to windows token service

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

I have configured a web part in SharePoint 2010. The environment consists of 1 WFE, 1 APP, 1 SQL, 1 AS server all on Windows Server 2008 R2 Sp1 OS. I have configured C2WTS. The user domainfarmaccountuser is also part of WSS_WPG group but i still get the following error:

Answers

Initially C2WTS config file allowed callers had only 1 entry of WSS_WPG. In this case C2WTS was actually not working although c2WTSTest.exe mentioned it would work.

To make C2WTS work i made two changes:

1. Changes to C2WTS config file:

Above shows that i added Authenticated Users

2. Added NT AuthoritySystem to local WSS_WPG group

The above was tough to figure out since i felt that this should have been done automatically by the service.

————————
This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

Yes farmaccountuser is local admin.

C2WTS domain account is also local admin. I followed the Kerberos guide step by step.

Does the C2WTS user also have the following rights on the server:

Act as part of the operating system

Impersonate a client after authentication

Logon as a service

————————
This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

Yes did do those as well.

Just to be exact, i have followed all the steps detailed in the article at:

The event viewer shows me following error message:

The source was not found, but some or all event logs could not be searched. Inaccessible logs: Security.

Silly question, but after adding it to the Local Admins group, did you force the account to log off of the system?

Have you modified, either via GPO or manually the SDDL of the Security Event Log?

————————
This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

Trevor, no problem i dont mind being elaborate.

I logged in using FarmAccountUser who was already local admin on the server(WFE and AppServer). While logged on as FarmAccountUser i configured C2WTS, also added the C2WTSSvcAccount to Local Admin and then logged off. Later logged on as FarmAccountUser which didnt help. Then finally restarted both WFE and AppServer. From CA i changed the service account C2WTS service from Local System to C2WTSSvcAccount. C2WTS is configured on both WFE and AppServer, although i understand it shouldnt run on WFE. But if i stop the server on WFE the error doubles up. I get below error in addition to the earlier error that I posted. Hence i had to start C2WTS on WFE as well.

I ran c2WTSTest.exe to check if C2WTS is configured properly. I get below message when i run the tool, which indicates that the service is running properly i guess.

Services running on the servers are as follows:

Источник

Claims to Windows Token Service (c2WTS) not starting after rebooting server

Symptom

There are occasions where Claims To Windows Token Service (c2WTS) is unable to start automatically after a reboot. The Application Event Log will also show that c2WTS timed out, and, in a later entry that Cryptographic Services Service was started. When c2WTS starts automatically, the Application Event Log will show Cryptographic Services Service starting before c2WTS. This can happen specially in SharePoint 2010 when Claims to Windows Service is configured in one or more servers.

Cause

Claims To Windows Token Service (c2WTS) has a dependency on Cryptographic Services but this dependency is not added to the service definition. Since the execution order of the services are not guaranteed to happen in any specific order unless it is defined in the service dependencies, it may lead to intermittent problems where c2WTS service will time out and fail to start. Observing the Application Event Viewer, you can see that Cryptographic Services Service was trying to start while c2WTS was also starting and it timed out just before Cryptographic Services Service has started.

c2WTS is part of the Windows Identity Foundation framework (WIF) which is one of the dependencies of SharePoint. The framework installation does not include the service dependency automatically.

Resolution

The solution is to make sure that Cryptographic Services Service is guaranteed to start before c2WTS starts by explicitly adding the dependency in the service definition. These steps will add the dependency:

1. Open the command-prompt window.

2. Type: sc config c2wts depend= CryptSvc
3. Find the Claims to Windows Token Service in the services console (click Start | Run | services.msc).

4. Open the properties for the service.

5. Check the Dependencies tab. Make sure Cryptographic Services is listed.

The next time the system reboots, Cryptography Services will start before c2WTS starts which resolves the dependency problem and the intermittent problem. If you are using SharePoint 2010 this must be done in all servers running the service.

More Information

Identity delegation for PerformancePoint Services (SharePoint Server 2010)

Источник

Кевин Лаахс (kevin.laahs@hp.com) — специалист по стратегическим технологиям в HP Enterprise Services

Доступ к контенту с авторизацией, предусмотренный в Microsoft SharePoint, рассматривался в статье «Основы безопасности SharePoint», опубликованной в Windows IT Pro/RE № 11 за 2012 год. Для присвоения прав доступа SharePoint должен уметь идентифицировать пользователя, который пытается получить доступ к контенту. Таким образом, идентификация пользователя является критичной для работы служб, таких как User Profile: идентификация пользователя управляет тем, что они могут делать с персональными домашними страницами и функциями социальных сетей.

Аутентификация – это часть общего процесса идентификации пользователя. В ходе аутентификации пользователи предоставляют особый ключ, чтобы SharePoint определил, кто они такие. Далее SharePoint использует этот ключ для связывания пользователя с внутренним объектом (называемым SPUser), который далее применяется при авторизации доступа к контенту.

В предыдущих версиях SharePoint этот ключ мог быть стандартным ключом системы безопасности Windows, представляющим собой либо пользовательский объект или группу безопасности Active Directory (AD), либо ключ, сгенерированный провайдером членства и ролей ASP.NET. Хотя он все еще поддерживает классическую идентификацию Windows, SharePoint 2010 также поддерживает и вариант идентификации на основе заявок, который приводит к некоторым дополнительным возможностям. Например, SharePoint может принимать участие в инфраструктуре аутентификации, которая не основана на Windows, получая в качестве преимуществ простое делегирование идентификации во внутренних приложениях, а также упрощенную и цельную среду для разработчиков решений.

.

Идентификация, основанная на заявках

При использовании заявок идентичность пользователя определяется рядом атрибутов, которые описывают пользователя: электронный почтовый адрес, полное имя, группа, к которой пользователь может принадлежать, страна проживания и даже могут быть более личные сведения, такие как номер паспорта или водительских прав. Служба выдачи этих сведений Active Directory Federation Services (ADFS), которой вы полностью доверяете, выдает по заявкам эти атрибуты и их значения.

Приложения, использующие заявки, имеют безусловные доверительные отношения со службой выдачи заявок. Эти приложения доверяют заявкам пользователей только в том случае, если приложение доверяет службе, которая выдала заявку. А если приложение доверяет службе, тогда приложению нет нужды беспокоиться о том, как служба аутентифицирует пользователя или откуда служба берет атрибуты и их значения. Таким образом, приложение не нуждается в каком-либо коде аутентификации внутри себя. Эта абстрактная схема аутентификации позволяет приложению работать в практически любой инфраструктуре идентификации, попросту обрабатывая заявки, которые ей предъявляются для определения идентичности пользователя. Облеченные доверием службы, которые выполняют аутентификацию, обычно называются провайдерами идентичности или провайдерам аутентификации.

Упоминание безусловного доверия важно. Без него системы идентификации, основанные на заявках, были бы невозможны. Ваше приложение должно выбрать центр идентификации, заявкам которого будет доверять. Рассмотрим такой атрибут, как возраст. Вы можете довериться людям, когда они указывают свой возраст, если его использование внутри вашего приложения служит для чисто информационных целей. Например, на самом деле неважно, ввожу ли я свой реальный возраст на страничке Facebook. Но если целью является верификация того, что кому-то законом разрешено покупать алкоголь, вы захотите получить ответ от более достоверного источника – некоего центра, который может подтвердить информацию, такого как отдел регистрации актов гражданского состояния.

SharePoint 2010 является приложением, использующим заявки, а это означает, что он на самом деле не беспокоится об аутентификации пользователя. Он беспокоится о получении ключа Security Assertion Markup Language (SAML), предоставляющего значения атрибутов, которые могут применяться для идентификации пользователя. Эта возможность позволяет SharePoint быть развернутым в средах, которые могут потребовать больше методов аутентификации, доступных через Интернет, чем может предоставить обычная система Windows. Это также означает, что вы можете вносить изменения в доступные методы аутентификации без изменения, повторной компиляции либо повторной настройки SharePoint или любых решений на его базе.

Вот один пример, который часто используется для высокоуровневого описания идентификации, основанной на заявках. Этот пример описывает посадку на самолет.

1. Когда вы подходите к выходу на посадку, вы предъявляете посадочный талон – в бумажном или электронном виде – сотрудникам аэропорта.
2. Сотрудники удостоверяются, что пропуск на посадку не является подделкой (используя штрих-код или магнитную ленту) и что он был выдан авиакомпанией.
3. Поскольку сотрудники доверяют авиакомпании, они доверяют деталям (то есть заявкам), таким как номер места, имя и номер рейса, которые есть на посадочном талоне.
4. Сотрудники разрешают вам посадку на самолет.

У вас есть разные способы получить посадочный талон, такие как регистрация по Интернету или на стойке регистрации. Независимо от того, как вы получили посадочный талон, вы должны предоставить некоторую учетную информацию (номер регистрации, паспорт или водительские права) для того, чтобы подтвердить свою личность, прежде чем талон будет выписан на вас.

По сути, посадочный талон является набором заявок, которые издаются и удостоверяются центром доверия, которому доверяют сотрудники у выхода на посадку. Сотрудники не думают о том, как вы получили посадочный талон или каким образом подтвердили, что вы – это вы. Это ключевое преимущество систем, основанных на заявках: они абстрагируют всю область аутентификации (включая эксплуатацию, вроде управления паролем) от приложения.

В терминах программного обеспечения, набор заявок называется ключом безопасности. Издатель подписывает каждый ключ. Приложение, основанное на заявках, считает, что пользователь аутентифицирован, если он предоставит действующий подписанный ключ безопасности от доверенного издателя. Неважно, какой был использован протокол аутентификации. Приложение получает ключ безопасности в простом стандартном формате (например, SAML), который приложение может, соответственно, использовать для определения аутентификации и уровней разрешений для конкретного пользователя. Также приложение может разрешить доступ к своим ресурсам, используя заявки, которые представляет пользователь.

Аутентификация, основанная на заявках

SharePoint 2010 поддерживает два способа идентификации пользователей. Применяемый метод определяется на уровне веб-приложения.

Первый способ известен как классическая аутентификация. Этот метод задействует идентификацию Windows для проверки пользователей и поддерживает только одного провайдера аутентификации: Windows (или AD). Второй метод известен как аутентификация, основанная на заявках. Этот метод использует заявки для идентификации пользователей и поддерживает трех провайдеров аутентификации — Windows (или AD), аутентификацию на базе форм и доверенных провайдеров идентичности. Все они могут быть использованы для одного и того же веб-приложения. Все эти провайдеры приводят к генерации ключа SAML и его последующего представления SharePoint, когда дается доступ к ресурсам.

Существует много причин, почему вам может потребоваться или вы просто захотите использовать что-то другое, а не идентификацию Windows в среде, в которой запускаете SharePoint:

• вы хотите предоставить контролируемый доступ по Интернету тем, у кого нет учетных записей в вашем домене AD;
• возможно, произошло слияние с другой организацией, и у вас еще нет доверительных взаимоотношений между разными лесами доменов, поэтому аутентификация Windows невозможна;
• вам нужно провести интеграцию с внутренним приложением, которое не запускается на Windows, и необходим способ делегировать идентификацию пользователей из SharePoint во внутреннее приложение.

SharePoint 2010 использует платформу Microsoft Windows Identity Foundation (WIF – бывшее кодовое имя Geneva Framework) для реализации идентификации, основанной на заявках. WIF представляет собой набор классов Microsoft. NET Framework, которые делают возможным создание приложений на базе запросов аутентификации WS-Federation. WS-Federation является протоколом аутентификации, который строится на двух других стандартных протоколах: WS-Trust и WS-Security. WS-Federation поддерживает архитектуру аутентификации, основанную на ключах, которая позволяет веб-приложению запрашивать секретный ключ для доступа к ресурсам с аутентификацией.

С идентификацией, основанной на заявках, SharePoint становится непривязанным к определенным провайдерам идентификации, таким как провайдеры аутентификации AD и ASP.NET, которые были единственными доступными провайдерами в SharePoint 2007. Вместо этого вы можете задействовать любого провайдера идентификации, который был спроектирован и реализован в соответствии со стандартами системы безопасности WS-*. Это означает, что вы можете использовать таких провайдеров идентификации, как Windows LiveID, OpenID (например, Google, Yahoo) и ADFS.

Но SharePoint на самом деле идет гораздо дальше. Помимо принятия запросов на аутентификацию от WS-Federation, SharePoint теперь принимает запросы Windows и запросы, основанные на формах аутентификации, и конвертирует их в заявку. Такое требование впоследствии может быть использовано внутри SharePoint для коммуникации со служебными приложениями и делегирования другим сторонним приложениям, которые поддерживают заявки. Более того, SharePoint также предоставляет заявки для службы Claims to Windows Token Service (c2WTS), которая может конвертировать заявку обратно в запрос Kerberos для интеграции с приложениями, которые не основаны на заявках.

Служба секретного ключа SharePoint

Чтобы отправить провайдеру идентификации неаутентифицированные запросы на ресурсы SharePoint и конвертировать возвращаемые секретные ключи в заявки (например, ключи SAML), в SharePoint предусмотрена собственная служба секретного ключа Security Token Service (STS).

STS является веб-службой, которая вступает в игру с любым веб-приложением, которое было активировано на аутентификацию, основанную на заявках.

На рисунке показаны высокоуровневые шаги, выполняемые при попытке пользователя получить доступ к ресурсу SharePoint.

Рисунок. STS в действии

1. Делается неразрешенный запрос HTTP по URL ресурса SharePoint.
2. SharePoint отвечает, показывая, что запрос не аутентифицирован, и выдает вызывающему приложению URL, по которому надо перейти для выполнения аутентификации. Этот процесс зависит от провайдеров аутентификации, которые активированы в SharePoint; например, вызов может быть перенаправлен на страницу регистрации Windows LiveID. Если доступно более одного провайдера аутентификации, тогда URL будет к странице регистрации, которая позволяет пользователю выбрать тип провайдера идентификации, с помощью которого он хочет выполнить аутентификацию.
3. Провайдер идентификации аутентифицирует пользователя для доступа к соответствующему ресурсу, будь то AD для Windows, провайдер членства в группе и роли для аутентификации, основанной на формах, или система, основанная на SAML, такая как ADFS или Windows LiveID.
4. Провайдер идентификации возвращает секретный ключ, который является особым для каждого метода аутентификации.
5. Этот специфичный для провайдера аутентификации секретный ключ предоставляется SharePoint STS. STS верифицирует, что он доверяет издателю секретного ключа и превращает ключ в ключ SAML, который подходит для использования внутри SharePoint (если провайдер идентификации вернул ключ SAML, тогда STS перегенерирует этот ключ). Заметьте, что реальные атрибуты в ключе SAML зависят от провайдера идентификации. На этом шаге ключ SAML может быть расширен за счет вашего собственного провайдера заявок, и это произойдет перед тем как вы передадите его вызывающему пользователю. Это расширение полезно для того, чтобы заявки для других приложений, таких как внутренние приложения (например, CRM), были уже включены в список заявок пользователя.
6. Ключ SAML возвращается пользователю.
7. Запрос HTTP с присоединенным ключом SAML делается к исходному URL. Далее SharePoint использует ключ SAML для определения того, разрешено ли пользователю получить доступ к требуемому ресурсу.

SharePoint STS является веб-службой, называемой SecurityTokenServiceApplication, и устанавливается на внешних серверах, на веб-сайте Microsoft IIS, который называется SharePoint Web Services.

Настройка аутентификации, основанной на заявках

Вы задаете настройки основанной на заявках аутентификации, когда создаете веб-приложение. Заметьте, что SharePoint не позволяет вам изменять режим аутентификации (основанный на заявках или классический) в разделе Central Administration после создания приложения. Вы можете использовать Windows PowerShell для конвертирования из классического режима в основанный на заявках, но не наоборот. Просмотрите статью TechNet под названием «Migrate from classic-mode to claims-based authentication (SharePoint Server 2010)» (http://technet.microsoft.com/en-us/library/gg251985.aspx), если хотите узнать детали. Настройка основанной на заявках аутентификации — несколько более сложный процесс, чем настройка классического режима, потому что вы должны подумать и о провайдерах идентификации. Задайте параметры ключевых настроек нового веб-приложения, которые относятся к основанной на заявках аутентификации.

1. На странице Manage Web Applications в Central Administration выберите новую задачу, пункт New в ленте меню.
2. На следующей странице выберите кнопку Claims Based Authentication вверху страницы.
3. В разделе Claims Authentication Types выберите провайдеров идентификации, которых намерены поддерживать (например, Windows, FBA или Trusted IP).
4. 4. Если вы определяете более одного провайдера идентификации, раздел Sign In Page URL предложит возможность замены страницы регистрации по умолчанию.

На экранах 1, 2 и 3 показана аутентификация с заявками в действии. Экран 1 показывает, что происходит, когда пользователь пытается зарегистрироваться на сайте SharePoint, на котором задана аутентификация с заявками как Windows, так и основанной на формах аутентификации (LDAP). Домашняя страница на сайте SharePoint имеет часть Web Part, которая показывает итоговые заявки запрашивающего пользователя. Эта Web Part была написана Стивом Пешкой, как указано в статье MSDN «Claims Walkthrough: Writing Claims Providers for SharePoint 2010» (http://msdn.microsoft.com/en-us/library/ff699494.aspx).

Экран 1. Страница регистрации с выбором аутентификации Windows или Forms

Экран 2. Домашняя страница аутентификации с?использованием провайдера аутентификации, основанного на формах LDAP

Экран 3. Домашняя страница аутентификации с?провайдером Windows

Разница между заявками, которые показаны на экранах 2 и 3 может быть вызвана различными IP, которые были задействованы при аутентификации пользователя. Хотя и применялся один и тот же источник данных (то есть тот же пользовательский объект в AD) в обоих сценариях, аутентификация Windows возвращает другой набор атрибутов, нежели аутентификация LDAP.

Гибкость в эксплуатации и возможности

Аутентификация, основанная на заявках, дает больше гибких возможностей для развертывания, чем классический режим, открывая дополнительные возможности для интеграции со средами, основанными не на Windows. Помните, что Windows является основанным на заявках провайдером, поэтому вы можете применять ту же самую идентификацию Windows, которую вы используете при регистрации. Кроме того, вы выигрываете от новых возможностей, которые дает основанная на заявках аутентификация. Чтобы определиться, внедрять ли классическую или основанную на заявках аутентификацию, почитайте статью TechNet «Plan for claims-based authentication or classic-mode authentication (SharePoint 2010)» (http://technet.microsoft.com/en-us/library/hh706161.aspx)