- Scenario overview
- Key considerations
- Recommended approach
- Alternative approach
- Project task overview
- Long term enhancements
Acme Inc. uses NTLM with Integrated Windows Authentication (IWA) with an Active Directory back end. In the use case for this scenario, they would prefer their users have a seamless, silent authentication experience with search after logging into the Windows domain and using Internet Explorer for browsing.
- Index and securely serve NTLM-protected content.
- Provide a general search box, which would return a results page with most relevant links across all indexed content.
- Present search results for secure content only to users authorized to see the content.
- Provide seamless silent authentication with search after a user initially logs into the Windows Domain.
- The IIS Server hosting the content accepts HEAD requests.
- All crawled content is under the same Windows Domain that users log into.
- Confirm the assumption that all content sources use the same Windows domain that users log into.
- Make sure all servers in the deployment architecture are time synched to the same time server.
- Make sure there is a certificate available in IIS that can be used to sign SAML Post binding requests.
- To enable communication with the SAML Bridge over HTTPS, configure the GSA with the root certificate of the SAML Bridge.
Google’s recommended approach for implementing silent authentication by integrating with NTLM and the SAML Bridge covers the following areas:
Acme Inc. will use the SAML Bridge to authenticate users with Active Directory, taking advantage of the silent authentication benefit provided by IWA. For this to work, the domain controller that is running Active Directory must meet the following requirements:
- Windows 2003 Kerberos Extension must be available as Kerberos is used for authentication between the SAML Bridge and the content server.
- The domain functional level must be set to Windows Server 2003.
- Active Directory must be configured to permit the SAML Bridge to use delegated credentials from the user to access content on the content server.
To configure the SAML Bridge for use by the GSA in performing authentication, use the Search > Secure Search > Universal Login Auth Mechanisms page in the Admin Console.
Since authorization with NTLM is required, the SAML Bridge will also be used for authorization. In this case, the SAML Bridge must be configured as the Authorization Provider on the Search > Secure Search > Access Control page in the Admin Console. The GSA will then delegate authorization checks for individual documents to the SAML Bridge. The SAML Bridge will respond with PERMIT or DENY, accordingly.
- A user creates a search query for secure content.
- The GSA’s Authentication SPI is used to delegate to the SAML Bridge for Authentication. NTLM, which is configured on the user’s browser, is used to authenticate the user.
- After authenticating the user, the GSA determines the most relevant results for the user. If these results contain secure documents, the GSA uses the Authorization SPI to delegate the authorization checks to the SAML Bridge for these documents.
- The SAML Bridge obtains a Kerberos ticket on the user’s behalf and impersonates the user to the content server.
- The SAML Bridge sends a PERMIT or DENY message back to the GSA and the GSA displays the results that a user is permitted to see on a search results page.
Switch to Kerberos as the authentication mechanism for content servers. Upon switching to Kerberos, there is the possibility that deploying the SAML Bridge can be bypassed in configuring silent authentication.
The following table lists the project tasks and activities for implementing silent authentication, integrating with NTLM and the SAML Bridge.
|Plan deployment architecture||
|Configure SAML Bridge on the GSA||
Perform an architecture review as new content sources are brought on to see if existing architecture needs to be modified for onboarding new content.