ADFS…Active Directory Federation Service – STEP by STEP installation for O365
A main tool for corporate network to maintain on-prem and cloud-prem on a single sign-on environment. Deployment of ADFS is always happening on-prem and will sync to the cloud to maintain the AD structure and security through..secure tunnel
Office 365 – cloud configuration – Live ADFS or Active directory Federation Service is to deploy a new AD FS 2.0 infrastructure to provide your Active Directory users, who are logged on to computers located physically on the corporate network or that are logged on remotely to the corporate network, with single sign-on access to Office 365 services using their corporate domain credentials. Once you have deployed your AD FS 2.0 production environment on-premises, you will need to establish a relying party trust relationship between the AD FS 2.0 federation server farm and Office 365. This relying party trust acts as a secure channel where authentication tokens can safely pass between your organization and Office 365 in order to facilitate single sign-on access to Office 365.
AD FS 2.0 supports software virtualization of both the federation server and federation server proxy roles…Certificates play the most critical role in securing communications between federation servers, federation server proxies, Office 365, and web clients. The requirements for certificates vary, depending on whether you are setting up a federation server or a federation server proxy.
ADFS Architecture
The core architecture of Active Directory Federation Services (ADFS) requires an Active Directory (AD) or Active Directory Application Mode (ADAM) instance that contains user credentials. ADFS doesn’t replace the existing account repository; rather, it extends the repository’s visibility to other organizations in a highly controller manner. ADFS is a security token service that’s used mainly to compile statements about the user account in the form of security tokens, For custom applications, ADFS also populates claims, which are statements about the security principal (e.g., username, user’s title), that the Web application uses to ascertain the level of access that should be given to the requesting user. ADFS also manages the federation trusts it shares with other organizations’ federated services. A federation trust isn’t an AD forest trust; rather, it’s a special trust that uses certificates for token signing between organizations. The trusting forest can’t use the federation trust to query information about accounts in the account forest. The only information the trust ever sees is when specific users attempt to access Web services in its forest, and then it sees only account information designated as appropriate for that relationship. Federated-services servers in different organizations never communicate with each other; all communication occurs via the requesting client, which means the ports that have to be open for a typical domain trust aren’t required for a federated trust. Creation of the federated trust is all done out-of-band with only the signing certificate for the account side of the trust required at both ends, which can be sent via an email or burned to media and sent via carrier. All communication from the client is via HTTP Secure (HTTPS, port 443).
I’m gonna talk more from the real time scenario of
Single sign-on:
Single sign-on, also called identity federation, allows you and your users to access services in Microsoft Office 365 for enterprises with your Active Directory corporate credentials. Without single sign-on, you, the administrator, and your users will need to maintain separate user names and passwords for your online and on-premises accounts. Single sign-on requires both Active Directory Federation Services (AD FS) 2.0 and Active Directory synchronization. When you set up single sign-on, you establish a relying party trust between AD FS 2.0 and Office 365. Local Active Directory users obtain authentication tokens from AD FS 2.0 that redirect the users’ requests through the relying party trust. This allows your users to access Office 365 without needing to sign in with different credentials.
AD FS 2.0 deployment
AD FS 2.0 supports software virtualization of both the federation server and federation server proxy roles.
AD FS 2.0 deployment to create a relying party trust successfully with Office 365, you must first make sure that your corporate network infrastructure is configured to support AD FS 2.0 requirements for accounts, name resolution, and certificates. AD FS 2.0 has the following types of requirements:
AD FS 2.0 software must be installed on any computer that you are preparing for the federation server or federation server proxy role. You can install this software by either using the AD FS 2.0 Setup Wizard or by performing a quiet installation using the adfssetup.exe /quiet parameter at a command line.
Installation platform: Windows Server 2008 or Windows Server 2008 R2.
During the AD FS 2.0 installation process, the setup wizard attempts to automatically check for and, if necessary, install both prerequisite applications and dependent hotfixes. In most cases the setup wizard will install all of the prerequisite applications necessary for AD FS 2.0 to operate and install. However, when you are installing AD FS 2.0 on the Windows Server 2008 platform. you will first need to make sure that .NET 3.5 SP1 is installed on the servers running Windows Server 2008 before installing the AD FS 2.0 software, as it is a prerequisite of AD FS 2.0 and it will not automatically be installed.
You must install AD FS 2.0 hotfixes after you have installed AD FS 2.0. Click here to download the hotfixes
Certificate requirements:
For securing communications between federation servers, federation server proxies, Office 365, and web clients. AD FS 2.0 requires an SSL certificate when configuring federation server settings. This is a standard Secure Sockets Layer (SSL) certificate that is used for securing communications between federation servers, clients, and federation server proxy computers. Please note that AD FS 2.0 requires this SSL certificate to be without a dotless (short-name) Subject name. Because this certificate must be trusted by clients of AD FS 2.0, use an SSL certificate that is issued by a public (third-party) CA or by a CA that is subordinate to a publicly trusted root.
Certificate Providers (Please make sure that all digital certificates expiring after December 31, 2013 request must have 2048-bit or greater key size…after December 31, 2012, 1024-bit keys will not be accepted for any certificates…click here to know more.)
Deploying ADFS Server – Farm. (For a standalone server, you just have to install on one of the server and publish it)
Why Farm ? When you host your email and SPS and Lync on the cloud/O365 and you have opt to go for a federated domain, your AD is sitting in your local network and users on the cloud needs to authenticate it. That is when the ADFS on a clustered/Farm is very important. Availability for this server is very important. For high availability, we need NLB (Network Load Balancing).
NLB provides many features that make it convenient to use:
Checklist for ADFS deployment.
TechNet Webcast: Designing and Planning for Active Directory Federation Services (ADFS) Deployment Blog: Office 365 – cloud configuration – Live
Maheshkumar S Tiwari edited Revision 4. Comment: corrected title,tag and few edits
Carsten Siemens edited Revision 3. Comment: fixed typos
Richard Mueller edited Revision 1. Comment: Removed (en-US) from title, modified title casing, added tag
Horizon_Net edited Original. Comment: added language tags
Can you tell me specifically why I have to do NLB first? I have a current setup with one server and I want to add another. My thinking is that I can add another server to my single farm ADFS then configure NLB on them. Can you give me any guidance on what I should do if I need to migrate from a single ADFS not setup as stand alone but farm, to now transfer myself to NLB with another server?