This site contains the documentation that is relevant to older WSO2 product versions and offerings.
For the latest WSO2 documentation, visit https://wso2.com/documentation/.
Configuring IWA on Linux
Integrated Windows Authentication (IWA) is a popular authentication mechanism that is used to authenticate users in Microsoft Windows servers. It uses Negotiate/Kerberos or NTLM to authenticate users based on an encrypted ticket/message passed between a browser and a server. Follow the instructions in the sections below to configure IWA for local or federated authentication in WSO2 Identity Server (IS).
Tip: This IWA authenticator is provided OOTB and was implemented from WSO2 IS 5.3.0 onwards. It uses Kerberos internally and is the recommended approach as it overcomes some limitations of the IWA authenticator provided in previous versions of WSO2 IS which was based on NTLM. If you still want to use the previous IWA authenticator that was based on NTLM, it is available as an extension. For more information on how to setup the NTLM-based IWA authenticator, see Configuring IWA Single-Sign-On.
The benefits of using the authenticator based on Kerberos vs the authenticator based on NTLM are as follows:
- Can be used on any operating system unlike NTLM which has to be run on a Windows server.
- Performance and security on Kerberos are better.
- For more information about IWA, see Integrated Windows Authentication
- To configure Active Directory as a user store, see Configuring a Read-write Active Directory User Store.
How IWA with Kerberos works
Setting up IWA
Add a DNS host entry in the Active Directory (AD) to map the IP address of the WSO2 Identity Server to a hostname. If there are multiple Kerberos domains, WSO2 IS should have a virtual host name for each Kerberos domain.
When adding the DNS entry, generally the first part of the hostname is given. The AD will append the rest with its AD domain. For example, if the AD domain is wso2.com, after you add a DNS host entry, the final result will be similar to the following:
Exampleidp.wso2.com
NOTE: Kerberos does not work with IP addresses, it relies on domain names and correct DNS entries only.
Open the
carbon.xml
file found in the<IS_HOME>/repository/conf
folder and set the hostname (idp.wso2.com
) in the<HostName>
tag.<HostName>idp.wso2.com</HostName> <MgtHostName>idp.wso2.com</MgtHostName>\
Open the
jaas.conf
file found in the<IS_HOME>/repository/conf/identity
folder and check if the configuration is as follows. (Refer this for more information on JAAS)Server { com.sun.security.auth.module.Krb5LoginModule required useKeyTab=false storeKey=true useTicketCache=false isInitiator=false; }; Client { com.sun.security.auth.module.Krb5LoginModule required useTicketCache=false; };
Register WSO2 IS using the same hostname (
idp.wso2.com
) in Active Directory. To do this, use the DNS tool on the machine that is running WSO2 IS to add an entry for the hostname (idp.is.local), and map it to the local ip address.Create a service account in the Active Directory for WSO2 IS or use an existing account. (For this tutorial, the sample username of the service account is is_linux).
Note: The account used for WSO2 IS needs to be different from the one used by the user to login to the application.
Run the following commands to register WSO2 IS as a service principal in Active Directory.
Note: Replace
is_linux
with the username of your service account in the command below. The format of the command is as follows:[setspn -A HTTP/<url of Identity Server> <service_account>]
setspn -A HTTP/idp.wso2.com is_linux setspn -A HTTP/idp is_linux
You can now set up IWA either as a local authenticator or as a federated authenticator.
Configuring WSO2 IS with IWA as a local or federated authenticator
Follow the steps above to set up IWA.
- Start the WSO2 IS server and log in to the management console.
- Navigate to Main>Identity Providers and click Add. Enter a name for the identity provider.
- Expand the Federated Authenticators section and then expand IWA Federated Configuration.
Fill in the fields as follows:
Field Description Sample Value Enable Enable this to enable a custom authenticator for the identity provider. Selected Server Principal Name The SPNName should be the SPN you registered in step 6 of Setting up IWA, with the Active Directory domain. The SPNName follows this format:
<service class>/<host>@<AD domain>
For example,
If the SPN is
HTTP/idp.wso2.com
, whereHTTP
is a service class (in this case,HTTP
is not the standard protocol; it is the service class) andIS.wso2.com
is the Active Directory domain, the SPNName will beHTTP/idp.wso2.com@wso2.com
HTTP/idp.wso2.com@wso2.com
Server Principal Password The SPNPassword should be the password of the service account associated with the SPN (the service account created in step 6 of Setting up IWA). - User store domains [Mandatory only if you want to use IWA as a local authenticator]
The mounted user stores in which you want the user’s existence to be checked in.
- To configure IWA as a local authenticator, mount the user store domain names of the relevant user stores that you expect the user to be in.
- To configure IWA as a federated authenticator, leave this field blank.
PRIMARY Configure your browser to support Kerberos and NTLM. The tabs below explain how to configure each browser.
Testing the IWA authenticator
- Set up IWA as a local authenticator or as a federated authenticator by following the steps above.
Download and set up the Travelocity sample application. To do this, follow the instructions on the Configuring Single Sign-On page.
Edit the service provider you created for the Travelocity sample, and expand the Local and Outbound Authentication section.
- Select Federated Authentication as the Authentication Type and select the identity provider you created above.
- Restart the Apache Tomcat server and run the Travelocity sample application from a Windows machine.
- Use hostnames only (no ip addresses).
- Check the configuration of the
jaas.conf
file, particularly theisInitiator=false
property under theServer
section (see step 3 of the Setting Up IWA section). Make sure that your service principal (IS) is associated with only one account.
If you get an exception with an error message similar to “Checksum failed”, check whether you have given the correct password.