KB40430 - How to switch an Active Directory authentication server instance from Legacy mode to Standard mode

Pre-requisites

• 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

Limitations

Some of the limitations of the Standard Mode:

1. 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

2. 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.
3. 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.
4. 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

1. Create backups of configuration by exporting the binary system configuration and user configuration files from PCS/PPS gateway device.
2. Login into to the admin GUI and open the already configured Legacy Mode AD Auth Server Instance that you would like to migrate.
3. Click on button Switch to Active Directory Mode under the section Active Directory Selection

4. Enter Kerberos Realm field value

5. Checkbox Save Credentials may be enabled.

6. 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.

7. 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)

8. 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. 

9. Check for Domain Join Status under the section Domain Join Configuration.

• 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.

10. 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.
11. To verify that the migration was successful login into the PCS/PPS device as an end-user.  If the below error message occurs