- DNS requirements: The Standard Mode heavily relies on the configured DNS Server (configured at System > Network > Overview) for the resolution of IP addresses of Domain Controllers (DC) for the domain. It initially queries the DNS server for the hostnames of domain controllers which provide the required services (using Service Location (SRV) locator resource records) and then subsequent resolution of those hostnames. If you would like to verify this requirement before proceeding further refer KB40432 for details.
- Kerberos Realm name: The Kerberos Realm name is a required configuration item. To validate you have the correct name you may use the Kerberos troubleshooting tools. Refer KB40432 for details.
- Synchronized clocks with Domain Controllers: The Standard Mode heavily relies on Kerberos protocol and so it is a requirement that the clock on your PCS/PPS gateway device is synchronized with the DC. The maximum clock skew allowed is 5 minute and this value cannot be changed on the PCS/PPS device side. Note: Using a NTP server will ensure that the PCS/PPS gateway device is synchronized with the Domain Controller. (NTP server can be configured at Status->Overview Page -> System Date and Time -> Edit)
- Service Account Credentials: Username and password required to join the domain should be readily available. This may be needed if the PCS/PPS device fails joining the domain initially and a reattempt is required. Note: For details on what specific Permissions should be available to this service account refer KB40401
- LDAP signing: PCS version 8.2R5 & higher and PPS version C5.3R5 & higher require LDAP Signing to be enabled on the domain controller. For details refer https://support.microsoft.com/en-in/kb/935834
Some of the limitations of the Standard Mode:
- Only one instance per Domain: A PCS/PPS device should have only one AD Auth Server instance per Windows domain. This limitation applies to the legacy mode as well. For example in an AD Forest, if the domains are:
- Parent Domain : COMPANY.COM
- Child domains : SALES.COMPANY.COM and ACCOUNT.COMPANY.COM
In this case only up to three standard mode AD Auth server instances can be configured (one for each domain specified above).
- Authentication Protocol: If in Legacy AD server under Authentication Protocols both NTLMv2 and NTLMv1 are enabled then in the migrated Standard AD Server the default protocol will be set as NTLMv2. Standard AD allows only one protocol to be chosen for communication at one time.
- Support for Groups Search Using LDAP: Standard Mode fetches group information using samba’s native methods and does not support groups search using LDAP method.
- Support for Domain Local Groups of Trusted Child Domains: The Active Directory standard configuration does not support “domain local groups” of trusted child domains for authorization. If domain local groups are required in role mapping rules then use a separate LDAP auth server instance server as the directory server.
Procedural Steps for the actual migration
It is recommended that these steps be performed during a maintenance window.
- Create backups of configuration by exporting the binary system configuration and user configuration files from PCS/PPS gateway device.
- Login into to the admin GUI and open the already configured Legacy Mode AD Auth Server Instance that you would like to migrate.
- Click on button Switch to Active Directory Mode under the section Active Directory Selection
- Enter Kerberos Realm field value
Kerberos Realm Name is the FQDN of the Active Directory domain. For example, if “DOMAIN” is the domain name (NetBIOS name), and DOMAIN.COM is the Kerberos realm name.
If in doubt please check with your AD infrastructure team for the exact Kerberos realm name, the above is only an example.
- Checkbox Save Credentials may be enabled.
Note: If this setting is not enabled, the credentials entered will be deleted from the configuration 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 as each PCS/PPS node independently joins the cluster.
- Set the appropriate value for field Maximum simultaneous connections per domain under section Domain Connections
- Maximum simultaneous connections per domain. Enter the maximum number of simultaneous domain connections (1 to 10).
- This field specifies the maximum number of simultaneous connections that the auth daemon should open to the domain controller of one domain. A value of greater than 1 can improve the scalability with simultaneous authentication requests. However, this field value should be judiciously used, especially if trusted domain setting is enabled. This value dictates how many authentication processes are created per domain. For example: if the maximum domain connection is configured as 4 and there are 5 trusted domains, there could be as many as 5*4+1 = 21 auth processes. Hence if there are many trusted domains, the domain connection value needs to be controlled by the administrator, failing which there could be too many auth processes created only for AD authentication purpose.
- By default, this field value is set to 2 if trusted domain setting enabled. If trusted domain is not enabled then the default value is set to 5.
Note: If Contact trusted domains is enabled, a value above 6 may degrade overall system performance.
- Select the option Enable periodic password change of machine account under section Machine account password change to change the domain machine account password for this configuration.
- Specify a frequency in days for the field Change machine password frequency. For example, every 30 days.
- Default value set to 0, means Period Password Change of machine account is disabled (recommended) However this setting is dictated by what the policy is on your domain controllers. For example if the policy is set to 30 days on domain controllers and you disable it on PCS/PPS side than user authentication may fail after 30 days)
- Click on Save Changes to allow the saving of configuration. This operation validates all the fields from the page and displays any error encountered during the validation. This step completes the migration process. Steps 9, 10 and 11 are optional steps for verifying and troubleshooting the migration process.
- Check for Domain Join Status under the section Domain Join Configuration.
The following colors are used to indicate status:
- Grey. 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 Status 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.
Note: 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 restarting 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.
- If the Domain Join Status appears persistently RED then Troubleshooting steps on tab Troubleshooting should be used for determining the root cause of the issue. Quick help for every operation specified on the Troubleshooting tab is available with hovering the mouse over the operation button.
- To verify that the migration was successful login into the PCS/PPS device as an end-user. If the below error message occurs
And from the USER ACCESS Logs, login failure reason is Login failed. Reason: No Roles as shown below:
Then the exact reason for the failure can be found out by activating the Policy Tracing for the user under the Maintenance->Troubleshooting->Policy Tracing and capturing the trace for the user authenticating and looking for the exact error. If the error points to some user groups not being fetched in Standard Mode AD server then those groups should be reconfigured in the role mapping rules.
12. If you experience any issues in a production environment you could switch back to the legacy mode by clicking the button 'Switch to Active Directory Legacy Mode' however this should only be used as a last resort option and only temporarily until the issue is resolved (as the legacy mode is deprecated in 8.3R1 and higher)