A couple of general ADFS and DirSync Questions

This question is answered This question is answered

Hello


We’d be grateful for the answers on ADFS and DirSync questions based on our Environment:


We are looking at Federating up to 30,000 users with Office 365. All users are within one domain. We prefer to use Virtual Servers whenever possible. For scalability we are planning to host the ADFS Database on an SQL 2008 server


Questions

  1. What information is actually stored in the DB? Is it configuration only or is transactional data stored?
  2. What is the effect of ADFS database being unavailable - How long ADFS  be sustained if the DB is offline? We are not sure if we should cluster the database, host on an existing cluster of have a standalone virtual node.
  3. In an environment with our number of users how large might be expect the Database to grow?
  4. For the DirSync server, are changes from the cloud pulled or pushed? I am not sure if the DirSync server requires a private or public IP address.

Many thanks






Verified Answer
  • Some responses for the AD FS questions

    #1: AD FS 2.0 stores trust information and configuration information on this. It also has a provision for storing transactional data. However, these scenarios are not relvant for Office 365 Identity Federation.

    #2: If the database is unavailable, AD FS 2.0 will start failing requests very quickly. Hence it is recommended for you to use a SQL cluster if you are using remote SQL as the store.

    #3: Given an only O365 scenario, the database will be very small.

    If the focus of AD FS 2.0 is only for Office 365 and with 30000 users, you could skip SQL and opt to use the Windows Internal Database. With this option, you are limited to being supported up to a maximum of 5 servers in the ADFS farm. Given your number of users, I don't believe that you need more than 3 servers to support the Office 365 load and one could have an additional node available if needed.

    The one thing to consider about Windows Internal database is the question of whether you will need the features that require shared database support like SQL in the future. The 2 key features that require these are

    1. SAML-Artifact Resolution: This scenario involves one use case for the SAML-protocol where a handle (not the token) is provided to the service provider and the service provider fetches the token by directly calling hte Identity provider. This is relevant when you want to constrain the authentication bandwidth between the identity provider and the user client. This feature is not used by any of hte Office 365 scenarios.

    2. Token replay detection: In this scenario, AD FS 2.0 is the federation provider (not the Identity provider) where it accepts SAML tokens to issue a token for the application. It is a security feature meant to prevent malicious users from replaying SAML-tokens in the event they manage to capture these SAML tokens. With Office 365, AD FS 2.0 only acts as the Identity provider and this feature is not pertinent.

    Hope this help.

    Cheers, Sam

All Replies
  • Some responses for the AD FS questions

    #1: AD FS 2.0 stores trust information and configuration information on this. It also has a provision for storing transactional data. However, these scenarios are not relvant for Office 365 Identity Federation.

    #2: If the database is unavailable, AD FS 2.0 will start failing requests very quickly. Hence it is recommended for you to use a SQL cluster if you are using remote SQL as the store.

    #3: Given an only O365 scenario, the database will be very small.

    If the focus of AD FS 2.0 is only for Office 365 and with 30000 users, you could skip SQL and opt to use the Windows Internal Database. With this option, you are limited to being supported up to a maximum of 5 servers in the ADFS farm. Given your number of users, I don't believe that you need more than 3 servers to support the Office 365 load and one could have an additional node available if needed.

    The one thing to consider about Windows Internal database is the question of whether you will need the features that require shared database support like SQL in the future. The 2 key features that require these are

    1. SAML-Artifact Resolution: This scenario involves one use case for the SAML-protocol where a handle (not the token) is provided to the service provider and the service provider fetches the token by directly calling hte Identity provider. This is relevant when you want to constrain the authentication bandwidth between the identity provider and the user client. This feature is not used by any of hte Office 365 scenarios.

    2. Token replay detection: In this scenario, AD FS 2.0 is the federation provider (not the Identity provider) where it accepts SAML tokens to issue a token for the application. It is a security feature meant to prevent malicious users from replaying SAML-tokens in the event they manage to capture these SAML tokens. With Office 365, AD FS 2.0 only acts as the Identity provider and this feature is not pertinent.

    Hope this help.

    Cheers, Sam