Access Control with AD FS: Cloud and Third-party Authentication Done Right

Enable Single Sign-On (SSO) across organizational boundaries and analyze log data from multiple environments. 

The traditional boundaries of the enterprise corporate network are breaking down. Cloud technology vendors, SaaS providers, and managed service providers have become intrinsic to the value that modern enterprises provide to their users and customers. 

This presents a unique challenge to security personnel who detect unauthorized activities by capturing and analyzing log data. When so much of that data is beyond analysts’ reach, it makes it impossible to conduct a meaningful investigation. 

Microsoft’s Active Directory Federation Service (AD FS) directly addresses this issue by providing Single Sign-On capabilities to Windows Server Operating Systems administrators, extending access and visibility to systems beyond the corporate firewall. That allows analysts to capture and investigate vital log data from partners, vendors, and cloud technology providers as if they shared the same network. 

How AD FS Works: Federated Identity Explained 

AD FS expands Microsoft’s traditional Active Directory technology to provide authentication services to third-party systems. It does this by conceptually grouping enterprises and their trusted business partners into a federation. Users can interact with various parts of that shared infrastructure through a federated identity. 

AD FS establishes a claims-based authentication process. Each user is identified by a set of claims that define their identity. These claims are then packaged into a secure token and issued and verified by the AD FS server and its participating partners. 

A typical step-by-step example might look like this: 

1. A sales employee navigates to a vendor’s website to look up a product’s pricing details. 
2. The vendor’s website requests the employee’s authentication token. 
3. The employee requests the token from the AD FS server.
4. The AD FS server issues a token that contains that employee’s particular set of claims. 
5. The employee forwards the token to the vendor website’s authentication service. 
6. The vendor’s website authorizes the user and grants access. 

In practice, these steps are highly optimized to eliminate user experience friction. Employees appreciate the time-saving automatic sign-in, and security analysts now have access to a much wider range of login and activity data, including data from third-party vendors. 

AD FS Requires Federated Provisioning and Identity Management 

Since AD FS functionality spans multiple environments, organizations must meet the prerequisites for federated provisioning before deploying AD FS. Security managers must deploy a solution for federated identity management, and that solution must be deployed throughout the wider federated environment, including its partner gateways. 

As an example of what a typical third-party integration looks like, IBM describes the process of installing the Tivoli Federated Identity Manager in four steps: 

• Planning federated provisioning 

• Installing software prerequisites 
• Completing a runtime installation worksheet 
• Installing the provisioning runtime component. 

How to Obtain and Analyze AD FS Logs 

AD FS provides two sets of logs for troubleshooting and security tasks. The Admin Log contains high-level data on issues surrounding the federated service, while the Trace Log offers much more granular detail into every process that takes place. 

The Trace Log is disabled by default, but security professionals will want to make sure their systems are ingesting Admin Log data. This can be done in the Event Viewer, by right-clicking on Applications and Services Log and opening the AD FS menu. Click on Admin to view the log. 

At this point, administrators can enforce policy settings to groups of relying parties and capture valuable log data from users’ interactions with those parties’ systems. AD FS includes built-in access control policy templates that describe common scenarios, and administrators can replace these with their own custom policies. 

How to Enable Security Auditing with AD FS 

• Click Start, open the Programs menu, go to Administrative Tools and open Local Security Policy. 

• Navigate to the Security Settings\Local Policies\User Rights Management folder, and then double-click Generate Security Audits. 
• On the Local Security Setting tab, verify that the AD FS service account is listed. If it is not present, click Add User or Group and add it to the list, and then click OK. 
• Run the following command on the command prompt: auditpol.exe /set /subcategory:"Application Generated" /failure:enable /success:enable 
• Close Local Security Policy, and then open the AD FS Management menu. 

To open the AD FS Management menu:  

• Click Start, open Programs, navigate to Administrative Tools, and then click AD FS Management. 
• In the Actions pane, click Edit Federation Service Properties.  
• In the Federation Service Properties dialog box, click the Events tab. 
• Select the Success Audits and Failure Audits check boxes. 
• Click OK and you’re finished! 

Note that the process described above is appropriate only when AD FS is running on a standalone member server. If it’s running on a domain controller, the process requires editing the Default Domain Controller Policy, not the Local Security Policy above.  

Streamline your auditing and eliminate friction for employees with AD FS. Questions? A Castra specialist is ready to help.