You can confirm that the SEG is performing certificate authentication by pushing a user’s profile to the device and testing whether or not the device is able to connect and sync with the configured SEG end-point.
If the device does not connect and displays a message that the certificate cannot be authenticated or the account cannot connect to EAS, then the problem is related to the configuration.
If Exchange server returns a 401, add NTLM and Negotiate as providers to Windows Authentication.
- Make sure that a certificate is being issued by the CA to the device by checking the following information.
- Go to the internal CA Server, launch the certification authority application, and browse to the issued certificates section.
Find the last certificate that was issued and it should have a subject that matches the one created in the certificate template section earlier in this documentation.
If there is no certificate then there is an issue with the CA, client access server (e.g., SCEP), or with the Workspace ONE UEM connection to client access server.
- Check that the permissions of the client access server (e.g., SCEP) Admin Account are applied correctly to the CA, and the template on the CA.
- Check that the account information is entered correctly in the Workspace ONE UEM configuration.
- Verify the Server URL and the SCEP Challenge URL contain the correct information and end with a “/”.
- Launch a browser and enter the SCEP Challenge URL. The website should prompt you for credentials. After entering the SCEP Admin Account username and password, it should return with the challenge passphrase.
- If the certificate is being issued, make sure that it is in the Profile Payload and on the device.
- Navigate to Devices >Profiles >List View. Click the action icon for the device and select </> View XML to view the profile XML. There is certificate information that appears as a large section of text in the payload.
- On the device, go to the profiles list, select Details and see if the certificate is present.
- Confirm that the certificate contains the Subject Alternative Name (or SAN) section and that in that section there is an Email and Principal name with the appropriate data. If this section is not in the certificate then either the template is incorrect of the certificate authority has not been configured to accept SAN. Refer to Step 4: Configuring IIS for Certificate Authentication on the SEG.
- Confirm that the certificate contains the Client Authentication in the Enhanced Key Usage section. If this is not present, then the template is not configured correctly.
- If the certificate is on the device and contains the correct information, then the problem is most likely with the security settings on the SEG server.
- Confirm that the address of the SEG server is correct in the Workspace ONE UEM profile and that all the security settings have been adjusted for allowing certificate authentication on the SEG server.
- A very good test to run is to manually configure a single device to connect to the SEG/EAS server using certificate authentication. This should work outside of Workspace ONE UEM and until this works properly, Workspace ONE UEM will not be able to configure a device to connect to EAS with a certificate.
- Refer to the External References and Documents section for a link to a step by step guide for configuring a device to connect to EAS using a certificate.
- If none of the steps above resolve the problem, try authenticating independent of Workspace ONE UEM. This is done by eliminating the Workspace ONE UEM (e.g., SEG) and only using a certificate to authenticate the device. If this doesn’t work then there are other problems occurring. Until those problems are resolved, you will not be able to use the SEG to handle certificate authentication.
- If you cannot authenticate, verify the clocks on the SEG and Kerberos. Kerberos produces a ticket for the SEG to authenticate the user on the mail server. The timestamp on that ticket must be no more than five minutes apart from the SEG’s time clock. Verify the time clock on the SEG and Kerberos are within five minutes apart. You also might want to consider the use of Network Time Protocol daemons to keep all time clocks synchronized.
- If you cannot authenticate, evaluate your network. If you only have one Kerberos server configured, it is possible the server is not operational. Without it, no one can log in. To stop this from occurring, you might consider using multiple Kerberos servers and fallback authentication mechanisms.