Using Active Directory
This topic describes integration with the Microsoft® Windows® platform Active Directory™ service.
Microsoft Windows Platform Active Directory Service Overview
This section describes support for using Ivanti Policy Secure with the Active Directory AAA service.
Understanding Active Directory
Active Directory is a directory service used in Windows domain networks. It is included in most Windows server operating systems. Enterprise servers that run Active Directory are called domain controllers. An Active Directory domain controller authenticates and authorizes users and computers in a Windows domain network.
When you use Active Directory as the authentication and authorization service for your Ivanti access management framework, users can sign in to Ivanti Policy Secure using the same username and password they use to access their Windows desktops. You can also use Active Directory group information in role mapping rules.
From 9.1R1 onwards, Active Directory Legacy Mode configuration will not be supported. If you have an existing Active Directory authentication server using Legacy Mode, first migrate to Standard Mode and then upgrade Ivanti Policy Secure. For the detailed migration procedure, refer KB40430
Active Directory Feature Support
Ivanti access management framework supports the following Active Directory features:
- Honors trust relationships in Active Directory and Windows NT environments.
- Supports Domain Local Groups, Domain Global Groups, and Universal Groups defined in the Active Directory forest.
- Supports use of Kerberos, NTLMv2, and NTMLv1 authentication protocols.
- Supports User Principal Name (UPN) format for usernames. The UPN must pass validation against the domain used by ICS system directly or by trust relationship. If a UPN is rejected , the UPN is not tried again against other domains.
Interoperability Requirements and Limitations
The following limitations apply to interoperability with Active Directory:
- The Ivanti access management framework uses Active Directory security groups, not distribution groups. Security groups allow you to use one type of group for not only assigning rights and permissions, but also as a distribution list for e-mail.
- Each Active Directory configuration you create for the Ivanti access management framework should use a different and unique machine account name.
- If the current Active Directory domain controller is not reachable, the user or machine authentication requests fail for a few seconds (less than 2 minutes) before attempting to authenticate users with another domain controller in the Active Directory domain.
- We do not support interoperation with Active Directory implementations that use the equal sign operator (=) in a group name, such as: "\=THIRD FLOOR GROUP". The Ivanti access management framework authentication process involves search operations that use the equal sign operator (=) when parsing server catalogs to retrieve group names, usernames and domain names, as well as user_SID and domain_SID values. You might encounter unexpected behavior that can affect normal processing of authentication services if a group name configured on your Active Directory server includes an equal sign operator (=).
- Active Directory versions Windows 2008, Windows 2018 R2 and later use a dynamic port range. The default start port is 49152 and the default end port is 65535. Therefore, if there is a firewall between the Ivanti service and the Active Directory Service, you must increase the remote procedure call (RPC) port range on the firewall. See Microsoft Knowledge Base article 929851.
- The Ivanti password management feature, which enables users to change their Active Directory passwords through the Ivanti service Web server, is not supported for users of trusted domains that do not trust the domain specified in the Ivanti Active Directory configuration.
- UPN format for user log in is not supported for MS-CHAP v2.
Understanding the Active Directory Standard Configuration
Active Directory standard configuration supports interoperability with any version of Active Directory, and is the required configuration mode to support authentication using MS-CHAP v2 with Windows 2008 R2 Active Directory Service. Machine authentication, for example, uses MS-CHAP v2.
Configuring Authentication and Authorization with Active Directory Service (Standard Mode)
To configure integration with Active Directory Service (standard mode):
- Select Authentication > Auth. Servers.
- Select Active Directory / Windows NT and click New Server to display the configuration page.
- Select Active Directory mode and complete the configuration as described in table.
- Save the configuration.
|
Settings |
Guidelines |
|---|---|
|
Mode |
|
|
|
Select one of the following modes: Active Directory—For recent versions of Windows Server. This table describes Active Directory mode. |
|
Base Configuration |
|
|
Name |
Specify a name to identify the server within the system. |
|
Domain |
Specify the NetBIOS domain name for the Active Directory domain. The system uses DNS to discover domain controllers in the Active Directory forest. It sends authentication requests to the domain controller at the closest site. Ensure that your DNS servers are configured to resolve the Active Directory domain controller fully qualified domain name (FQDN) and service (SRV) records. |
|
Kerberos Realm |
Specify the FQDN of the Active Directory domain. For example, if “ivanti” is the domain name (NetBIOS name), then ivanti.com is the Kerberos realm name. |
|
Domain Join Configuration |
|
|
Username |
Specify a username that has permission to join computers to the Active Directory domain. Use the “Delegate Control” workflow in Active Directory to assign the following user account permissions to the username or to a group to which the user belongs:
|
|
Password |
Specify the password for the special user. |
|
Save Credentials |
If this setting is not enabled, the credentials entered will be destroyed after successfully joining the domain. This option is useful when managing clusters. For example, you might want to save the credentials for a cluster node you have yet to add. If you do not enable this option, you must manually enter the credentials when you add the new cluster node. |
|
Container Name |
Specify the container path in Active Directory in which to create the machine account. Changing this field triggers a domain rejoin action. The default is Computers, which is a standard container created during installation of the AD server. The AD Computers container is the default location for new computer accounts created in the domain. If desired, you may specify a different container or OU. To specify nested containers, use a forward slash ( / ) as the container separator. For example: outer OU/inner OU. Do not use backslashes in the path. Using backslashes causes an Invalid DN Syntax error. |
|
Computer Name |
Specify the machine account name. The default computer name is derived from the license hardware in the following format: 0161MT2L00K2C0. We recommend the Computer Name string contain no more than 14 characters to avoid potential issues with the AD/NT server. Do not include the '$' character. |
|
Update Join Status / Reset Join |
The following colors are used to indicate status: Gray. The Domain Join action has not been attempted. This is the default status that appears when you are using the page to create a new Active Directory configuration. Yellow. Attempting to join the Active Directory domain. This is the default status that appears after saving configuration settings or when any domain join settings are changed in an existing configuration. Green. The attempt was successful. This status indicates that this server can now be used to authenticate users. Red. The attempt to join the Active Directory domain was not successful. Click Update Join to get the latest join status of nodes. If the status appears persistently red, click Reset Join to reinitiate the domain join process. The Reset Join action requires Active Directory administrator credentials. For cluster nodes, you might need to click Update Join multiple times to obtain the latest join status of nodes. Transient network issues might also cause the join status indicator to appear red. Before reinitiating the join process, ensure that it is not caused by network issues. Make sure your DNS servers can resolve queries to the Active Directory domain controller and that the Active Directory credentials are valid and have the appropriate permissions. |
|
Additional Options |
|
|
Authentication Protocol |
The system attempts authentication using the protocols you have enabled in the order shown on the configuration page. For example, if you have selected the check boxes for Kerberos and NTLMv2, the system sends the credentials to Kerberos. If Kerberos succeeds, the system does not send the credentials to NTLMv2. If Kerberos is not supported or fails, the system uses NTLMv2 as the next protocol in order. |
|
Kerberos. Select this option to enable the Kerberos authentication protocol. Kerberos is the most secure method and is required for Kerberos single sign-on authentication. Kerberos must be enabled if you plan to use Ivanti single sign-on or browser-based agentless single sign-on (SPNEGO). |
|
|
Enable NTLM protocol. Select this option to enable NTLM if you plan to use any of the following features: Machine authentication using Ivanti Secure Access Client, or Windows native 802.1x supplicants. MS-CHAP-based authentication protocols for any 802.1x supplicants. User password management. Role mapping rules based on group membership. If you enable NTLM, select one of the following versions: NTLMv2. This protocol is moderately secure. It is required for machine authentication and MS-CHAP v2 based 802.1x authentication protocols. NTLMv1. This protocol is comparatively less secure. It might be required for compatibility with existing legacy servers, MS-CHAP based servers, and MS-CHAP based 802.1x authentication protocols. |
|
|
Trusts |
Contact trusted domains. Select this option to contact domain controllers of trusted domains directly without proxying authentication requests and group membership checks through the domain controller. If this option is not selected:
Network contact with trusted domains is not permitted, but pass-through authentication using the primary domain is still permitted. Trusted domain user's group lookup for Kerberos SSO and SPNEGO authentication does not work even though user authentication succeeds. Trusted domain user's password-based authentication does not work. Only groups from the domain in which this system is a member are available for use in role mapping when a group search is performed in the server catalog window. If you want to restrict trusted domain users and computers (machine authentication) from logging in when this option is not selected, you can define a custom expression based on the ntdomain variable and use it in role mapping rules. For example, if Ivanti Policy Secure belongs to the domain named Corporate, you can define a custom expression as ntdomain=Corporate and use the custom expression in the role mapping rule of the realm. |
|
SPNEGO Single Sign On |
Enable SPNEGO. Select this option to support SPNEGO SSO. |
|
Keytab Upload. Select this option to use the controls to upload the SPNEGO keytab. The keytab must be generated on the Active Directory Service for the SPN. It must match the FQDN used to access this device. |
|
|
Machine account password change |
Enable periodic password change of machine account. Select this option to change the domain machine account password for this configuration. |
|
Change machine password frequency. Specify a frequency in days. For example, every 30 days. |
|
|
Logical Auth Server Name |
Specify a logical authentication server name. |
You can troubleshoot the configurations using the Troubleshooting Tab for the respective server. You will be able to view this option on configuring the respective server. Using the troubleshooting option, you can validate:
- Domian Joint Status
- Authentication sucess status
- DNS Look-up for the respective servers
- Authentication Statistics