Introducing to AD FS
Active Directory Federation Services (AD FS) allows single sign-on access to Web-based resources, even when resources are located in a different network belonging to another organization.
AD FS is designed to work over the public Internet with a Web browser interface. The main purpose of AD FS is to allow secure business-to-business transactions over the Internet; users need to log on only to their local networks. AD FS servers and ADFS-enabled Web servers then manage authentication and access to resources on partner networks without additional user logons.
Federation Trusts
A federation trust, like other types of trust relationships, involves a trusting party and trusted party. Because AD FS is designed to facilitate business partnerships, the term “partner”is used instead of“party.” A federation trust is inherently a one-way trust, but a two-way trust could be formed simply by creating a trust in both directions.
In AD FS terminology, the trusted company is referred to as the account partner, and the trusting company is referred to as the resource partner.
Account Partners and Resource Partners
User accounts in the account partner can be Active Directory or AD LDS user accounts. The resource partner organization hosts applications and other resources that are accessible to account partner users.
When a user in the account partner organization wants to access these resources, a federation server in the account partner’s network presents a security token representing the user’s credentials to Web resources in the resource partner’s network. Based on the security token, the federation server in the resource partner’s network grants or denies access.
In AD FS parlance, the user credentials packaged in the security token are called claims.
Claims-Aware Applications
A claim is an agreed-on set of user attributes that both parties in a federation trust use to determine a user’s credentials, which specify the user’s permissions to resources in the partner’s network. Claims typically include a user’s logon name and group memberships and can include other attributes, such as department, title, and so forth. A claims-aware application is an ASP.NET application that makes user authorization decisions based on claims packaged in AD FS security tokens.
Windows NT Token Applications
Applications that aren’t claims aware can still participate in AD FS. These applications rely on Windows NT-style access tokens to determine user authorization. These tokens contain traditional user and group security principal SIDs, and access control lists(ACLs) are used to determine user permissions to a resource. An NT token-based application is an IIS application that relies on standard Windows authentication methods rather than claims.
AD FS role Services and components
The role services that are installed usually depend on whether you’re installing AD FS in an account partner’s or a resource partner’s network:
- Federation Service—The function of the Federation Service role service depends on whether the network where it’s installed is acting as an account partner or a resource partner. When used in an account partner network, its function is to gather user credentials
into claims and package them into a security token. The security token is then passed to the federation service on the resource partner network. The federation service on the resource partner network receives security tokens and claims from the account partner and presents the claims to Web-based applications for authorization. Servers with this role service installed are referred to as federation servers.
- Federation Service Proxy—Installed on servers in a perimeter network outside the corporate firewall, a federation service proxy fields authentication requests from browser clients and passes them to the federation server inside the firewall. A server configured as a federation service proxy protects the federation server from exposure to the Internet. The Federation Service and Federation Service Proxy role services can’t be installed on the same server.
- AD FS Web agents—A Web server can host the Claims-aware agent or the Windows token-based agent role service. These servers are called ADFS-enabled Web servers. Web agents manage security tokens sent by a federation server to determine whether the user
whose credentials are described in the token can access applications hosted by the ADFSenabled Web server.The two role services that are available are as follows:
• Claims-aware agent: An AD FS Web agent that handles security tokens using claims.
• Windows token-based agent: An AD FS Web agent that handles Windows NT-based tokens.
Starting with Windows server 2012 R2, AD FS deployment has been simplified: You just install the AD FS role. There are no additional role services to choose. The function of a federation service proxy and Web agents are now provided by the Web Application Proxy role service under the Remote Access Role and must be installed on a separate server from the AD FS role. The server running Web Application Proxy is installed on the perimeter network when you need to provide federation services to clients on untrusted networks.
Term and components
- Claims providers : A server that supplies a user with claims to present to the resource partner for access to federated resource. The claims provider works with Active Directory to verify the authenticated user and then builds the claim based on user attributes. The assembled user attributes depend on the requirements of the resource partner.
- Relying party: The resource partner that hosts the resources accessed by the account partner. It processes and validates claims issued by the claims provider and presents a token that grants access to a resource.
- Relying party trust: A Relying party trust is an AD FS trust created on the AD FS server that acts as the claims provider in an AD FS deployment. This trust causes the claims provider to trust the relying party claims are being made for.
- Claims provider trust: A trust created on the AD FS server that acts as the relying party or resource partner. This trust causes the relying party (resource partner) to trust the claims provider so that claims supplied by the claims provider are considered reliable.
- Claim rules: Claim rules are conditions that determine what attributes are required in a claim and how claims are processed by the federation server. There are two types of claim rules: relying party trust claim rules and claims provider trust claim rules.
- Attribute store: An LDAP-compatible database that stores the values in claims. AD is the most commonly used as the attribute store, but other LDAP databases and MS SQL server can also be used.
Web SSO
The simplest of the AD FS designs, the Web SSO provides single sign-on access to multiple Web applications for users who are external to the corporate network. This design is most often used in consumer-to-business relationships. There’s no federation trust between federation servers, as with other AD FS designs, because this design has only one federation server.
A username and password must be created for each user in a directory service, such as AD LDS. Credentials are presented to the federation proxy server, which forwards them to the internal federation server, which in turn issues a security token after successful authentication.
The perimeter network in the figure is sometimes referred to as a DMZ,and there’s a firewall (not shown) between the perimeter network and the internal network.
1. A user attempts to access an application on the ADFS-enabled Web server.
2. The ADFS-enabled Web server refuses access and redirects the browser to the federation proxy server’s logon page.
3. The user’s browser requests the logon page from the federation proxy server.
4. The user enters logon credentials, and the federation proxy server passes them to the federation server in the internal network.
5. The federation server validates the credentials with a directory server, such as AD LDS.
6. The federation server receives credential information from the directory service and creates the security token.
7. The security token is passed back to the client with the URL of the application on the ADFSenabled Web server.
8. The client presents the security token to the Web server and accesses the application.
Federated Web SSO
A trust relationship is established between the resource partner and the account partner. A federation server is running on both networks. Although not shown in the figure, federation proxy servers are often used in this design to enhance security. The Web SSO design is inherent in this design, where Internet users who aren’t part of the trust can still access Web applications in the resource partner network. In this situation, the account partner users request Web services from the resource partner. The resource partner doesn’t authenticate the user locally, but redirects the user back to the federation server in the account partner network. The account federation server validates the credentials and creates a security token for the client to present to the resource federation server. The federation server creates a security token for the client to present to the ADFS-enabled Web server, and the client requests the application. The federated Web SSO design
supports business-to-business relationships for collaboration or commerce purposes.
Federated Web SSO with Forest Trust
The federated Web SSO with forest trust design involves a network with two Active Directory forests. One forest, located in the perimeter
network, is considered the resource partner. The second forest, located in the internal network, is the account partner.
A forest trust is established between domain controllers in both forests. In this design , internal forest users and external users have access to ADFS-enabled Web applications in the perimeter network. External users have Active Directory accounts in the perimeter forest, and internal users have accounts in the internal forest. This design is used most often when Windows NT token applications are hosted on the Web servers. The AD FS Web agent running in the perimeter network intercepts authentication requests and creates the NT security tokens the Web applications need to make authorization decisions. The forest trust enables the Web agent to authenticate users from the internal network. External users are authenticated because the Web agent server is a member of the perimeter network forest. The federated Web
SSO with forest trust design is most often used in business-to-employee relationships and allows both internal and external employees to access ADFS-enabled Web applications.
Requirement
Requirements to consider:
• AD FS 2.1 is supported by Windows Server 2012 / R2 , to use Web Application Proxy instead of Federation Proxy, use 2012 R2 servers.
• Federation servers, federation proxy servers, and Web servers hosting AD FS Web agents must be configured with Transport Layer Security/Secure Sockets Layer (TLS/SSL), which is used by the HTTPS protocol. Firewalls must permit HTTPS traffic.
• Web browsers on client computers must have JScript and cookies enabled.
• One or more account stores, such as AD DS or AD LDS, must be running on the network. However, running AD DS on the same server as any AD FS role services isn’t recommended.
• Certificates are required by federation servers, federation server proxies, and ADFSenabled Web servers. Certificates can be requested from a public certification authority (CA) or internally from an AD CS CA. Optionally, you can self-sign certificates, which works well for testing environments.
As you have seen in the figures of AD FS designs, installing and testing AD FS requires a complex network environment and several computers. Setting up and testing AD FS with the simplest design, Web SSO, requires at least four computers. Other designs could require up to eight computers, if proxies are used.
Following is an overview of the steps for implementing a Web SSO design in windows 2012/R2:
Before these steps, you need to make sure you have a KDS root key.
Create one and allow all domain controllers to converge their AD replication straight away by CMDlet :
add-kdsRootKey -EffectiveTime (get-date).Addhours(-10)
To know the meaning of this command and parameters (such as -10), go here more about KDS root key: https://technet.microsoft.com/en-us/library/jj128430(v=ws.11).aspx
1. Create a service account to be used by the AD FS role
New-ADServiceAccount account_name -DNSHostName FQDN -ServicePrincipalNames http://FQDN
- The account_name is the service account that will be used later.
- FQDN is the server name in which you are installing the AD FS with domain name.
2. Install the Web server certificate. (first you need to create one if you don’t have one, http://frankfu.click/microsoft/windows-fundamental/certificate-service/)
When you install the certificate, you need to do additional configuration ( More information is required to enroll for this certificate)
In the subject tab, click the arrow under Type, and click Common name. then type the FQDN of your server in the value, click ADD. in the Alternative Name section, choose DNS in Type:, then type the FQDN of your server in the value.
3. Install the Federation Service role service on a server in the internal network
4. Install the Federation Service Proxy role service or the Web Application Proxy Role service on a server in ther perimeter network (Optional)
5. Install the Web Server role service and the AD FS Web Agent role service on your AD FS-enabled Web server.
6. Install AD DS or AD LDS to maintain the account store (the database containing user accounts). With Web SSO designs, AD LDS or a similar LDAP-compatible account store is usually used.
7. Install the claims-aware or Windows NT token-based application on the Web server.
Following is an overview of the steps for implementing a Web SSO design in windows 2008/R2: 1. Install the Federation Service role service on a server in the internal network. Most of these steps involve several substeps, such as issuing certificates, configuring DNS, and so forth. The Microsoft Technet Web site provides a thorough step-by-step procedure for deploying each AD FS design at http://technet.microsoft.com/en-us/library/cc771833.aspx and http://technet.microsoft.com/en-us/library/dn486820.aspx . Relying party is the resource partner that accepts claims from the account partner to make authentication and authorization decisions. To configure relying party trust, right-click the “Relying party trusts” folder in the AD FS console and click Add relying party trust to start the wizard. https://technet.microsoft.com/en-us/library/dd807108(v=ws.11).aspx Select data source: You specify how the wizard gets information about the relying party. This information is the metadata the relying party needs to create the trust, including the SSL certificate. It’s usually published by the claims-aware application that users will access via federation services. Options: In Server Manager, click Tools, and then select AD FS Management. In the AD FS snap-in, under the AD FS\Trust Relationships, right-click Claims Provider Trusts, and then click Add Claims Provider Trust to open the Add Claims Provider Trust Wizard. https://technet.microsoft.com/en-us/library/dn486771(v=ws.11).aspx A claim provider claim rule determines what claims AD FS issues. Claim rules are configured on the attribute store, which by default is the AD. Another term for claims provider rules is “acceptance transform rules”. A claim rule can pass a claim through to the relying party, or it can perform a transformation on the rule if certain attributes from the claims provider must be mapped to attributes the relying party can accept. For example, the claims provider can use the attribute “Group” to define a type of user, and the relying party can use the attribute “role”. A claim rule can transform the claim by changing the “group” attribute to “role” so that it’s accepted by the relying party. To configure: On the Start screen, type AD FS Management, and then press ENTER. In the console tree, under AD FS\Trust Relationships, click either Claims Provider Trusts or Relying Party Trusts, and then click a specific trust in the list where you want to create this rule. Right-click the selected trust, and then click Edit Claim Rules. In the Edit Claim Rules dialog box, select one the following tabs, depending on the trust that you are editing and which rule set you want to create this rule in, and then click Add Rule to start the rule wizard that is associated with that rule set. https://technet.microsoft.com/en-us/library/dd807068(v=ws.11).aspx You can also change the order in which claim rules are processed by selecting a rule and clicking the up or down arrow. Authentication policies enable you to determine what type of authentication is required in the AD FS system. In Server Manager, click Tools, and then select AD FS Management. In AD FS snap-in, click Authentication Policies There are two types of authentication policies: More configuration steps: https://technet.microsoft.com/en-us/library/dn486781(v=ws.11).aspx A new feature that allows nondomain-joined devices to access claims-based resources securely. –Used to deal with “bring your own device (BYOD)” –Usually done by installing the CA certificate on the mobile device –You must configure the device registration service on the AD FS server –Initialize-ADDeviceRegistration : Enter the name of the service account you created , here be sure to add a dollar sign ($) at the end of the name: E.g. frankfu\ADFSsvc$ –Enable-AdfsDeviceRegistration : After the command runs, click Edit in the primary authentication section ,and click “Enable device authentication” check box. Join To workplace from any device: https://technet.microsoft.com/en-us/library/dn280945(v=ws.11).aspx SSO in AD FS and office365: http://gshao.blog.51cto.com/3512873/1788027
2. Install the Federation Service Proxy role service on a server in the perimeter network (optional).
3. Install the Web Server role service and the AD FS Web Agent role service on your ADFSenabled Web server.
4. Install AD DS or AD LDS to maintain the account store (the database containing user accounts). With Web SSO designs, AD LDS or a similar LDAP-compatible account store is usually used.
5. Install the claims-aware or Windows NT token-based application on the Web server.
Relying Party Trust
Configure A claim provider trust
Configure A claim provider claim rules
Configure authentication Policies
Workplace Join
Reference