Troubleshooting SCEP certificate profile deployment to Android devices in Microsoft Intune

-

Introduction

This guide provides an architectural overview of SCEP certificate profile deployment to Android devices in Microsoft Intune, including how to verify that each step is successful. It also provides troubleshooting suggestions for some of the most common issues that you may encounter during the deployment process.
It's assumed that you have configured the NDES server, the Trusted Root profile and SCEP profile. In the example in this guide, the Trusted Root and SCEP profiles are named as follows:
  • Trusted Root Profile: AndroidNorthEndRootCert
  • SCEP profile: AndroidSCEP

Overview of SCEP communication flow

NDES and SCEP issues are some of the most challenging problems that may be encountered when you use Microsoft Intune. Having a basic understanding of the architecture and the communication flow of the SCEP process helps you identify or narrow the scope of the issue. It's important to understand how to collect logs, what logs to collect and what entries are important in each log during each step of the communication flow.
Before you move into SCEP certificate deployment, let’s look at the log files that log the various activities. These log files provide important insight to problems that might occur and help you understand the overall flow.

Log files on server side:

  • Microsoft Intune Connector log files
    FilesLocationDescriptionNote
    NDESConnector__
    (Example: NDESConnector_2018-06-17_010344.svclog)
    		%programfiles%\Microsoft Intune\NDESConnectorSvc\Logs\LogsLogs communications between the NDES Intune connector and Intune cloud service. The related registry entry: HKLM\SOFTWARE\Microsoft\MicrosoftIntune\NDESConnector\ConnectionStatus.We recommend that you use Service Trace Viewer Tool to view the log files.
    CertificateRegistrationPoint__
    (Example: CertificateRegistrationPoint_2018-03-07_214704.svclog)
    		%programfiles%\Microsoft Intune\NDESConnectorSvc\Logs\LogsLogs NDES receiving and verifying certificate requests.We recommend that you use Service Trace Viewer Tool to view the log files.
    NDESPlugin.log%programfiles%\Microsoft Intune\NDESPolicyModule\Logs\Logs passing and the results of verifying certificate requests to the Certificate Registration Point. 
  • IIS log files
    Files: u_ex

Log files on Android devices:

The OMA DM log from the Android Company Portal logs contain all the necessary information to troubleshoot SCEP deployment issues on the devices. To get Company Portal logs from an Android device, follow these steps:
  1. Open the Company Portal app.
  2. Tap Menu > Help > Email Support.
  3. Tap Send Email & Upload Logs.

The SCEP certificate deployment process

The following graphic demonstrates a basic overview of the SCEP communication process:
SCEP process

This six-step communication process forms the outline of the troubleshooting process. If you know which step that you’re experiencing a problem, select it from the following list. Otherwise, start with step 1 and review each step in order:

Step 1: Deploy the SCEP certificate profile

Note As a prerequisite for SCEP certificate, you must have already deployed the root certificate through a trusted certificate profile.
step1

In the first step, an Intune SCEP profile is deployed to a group of users.
AndroidSCEP

Assignment

The profile comes down as SyncML and resemble the following in the OMA DM log from the Android Company Portal Logs:

Troubleshooting

To verify that the SCEP profile is deployed to the device, follow these steps:
  1. Go to the Intune Troubleshooting Blade in the Azure Portal, then verify the following:
    • The profile is assigned to the correct security group.
    • The user is in the targeted security group.
    • The device has successfully checked into Intune.
    The following is an example:

    Troubleshooting Blade
  2. Get the SCEP policy ID from Azure Portal.

    Policy ID
  3. Search the OMA DM log for the policy ID of the SCEP profile. In the example, you can see the SCEP policy ID 39907… is found in the OMA DM log.
Back to top

Step 2: The device gets the SCEP profile and contacts the NDES server

step 2

In the second step, the device uses the URI in the SCEP profile and contacts the IIS/NDES server. When this happens, you can find entries that resemble the following in the OMA DM log from the Android device:
The connection is also logged by IIS in the %SystemDrive%\inetpub\logs\LogFiles\W3SVC1\ folder. The following is an example:

Troubleshooting

To verify that step 2 is completed successfully, open the most current log file in the %SystemDrive%\inetpub\logs\logfiles\w3svc1\ folder, then look for entries that resemble the following:
If the status code for the GET request for mscep.dll is 200, the connection with the NDES server is successful. For more information about the HTTP status code, see The HTTP status code in IIS 7 and later versions.
If the status code is 500, for example:
The issue occurs if the Impersonate a client after authentication user right isn’t assigned to the IIS_IURS group.
To fix this issue, follow these steps:
  1. Open Local Security Policy by typing secpol.msc in the Run dialog box, and then press ENTER.
  2. Expand Local Policies, and then click User Rights Assignment.
  3. Double-click Impersonate a client after authentication in the right pane.
  4. Click Add User or Group…, enter IIS_IURS in the Enter the object names to select box, and then click OK.
  5. Click OK.
  6. Restart the IIS/NDES server, and then try again.
If the status code is neither 200 nor 500, follow these steps:
  1. Find the SCEP server URL from the SCEP certificate profile.

    SCEP server URL
  2. Open a web browser, and then browse to the SCEP server URL. The expected result is the HTTP Error 403.0 – Forbidden error.

    403 error
If you don't receive the HTTP Error 403.0 – Forbidden error, select the error message that you receive:
Show all
Important Before the SCEP certificate can be successfully installed on the Android device, you must have root CA and intermediate CA certificates deployed to the device. For more information, see Missing intermediate certificate authority.
If there is a missing intermediate certificate, you receive the following errors in the OMA DM log:
Back to top

Step 3: NDES forwards the request to the NDES Connector policy module

step 3

In step 3, NDES forwards the request to the NDES Connector policy module which validates the request.
To verify that this step is successful, check the following:
  1. On the IIS/NDES server, look for entries that resemble the following in NDESPlugin.log:
     
  2. Look for entries that resemble the following in CertificateRegistrationPoint.svclog:

    Log
  3. Look for an entry that resembles the following in the IIS log:
     

Troubleshooting

  • If you don’t see the expected entries in NDESPlugin.log, verify that you have performed all troubleshooting steps in Step 2: The device gets the SCEP profile and contacts the NDES server.
  • Check whether you receive error 12175 in NDESplugin.log:
    Modern browsers and browsers on mobile devices ignore the Common Name on an SSL certificate if there are Subject Alternative Names present.

    To fix the issue, issue the web server SSL certificate with the following attributes for Common Name and Subject Alternative Name, and then bind it to port 443 in IIS:
    • Subject name
      CN = external server name
    • Subject Alternative name
      DNS Name= external server name
      DNS Name= internal server name
  • Check whether you receive error "403.16 – Forbidden: Access is denied" in NDESPlugin.log:
    The following is logged in IIS log:
    Error 403.16 means that client certificate is untrusted or invalid.

    This issue occurs if there are intermediate CA certificates in the NDES server's Trusted Root Certification Authorities certificate store.

    If a certificate has the same Issued to and Issued by values, it's a root certificate. Otherwise, it's an intermediate certificate.

    To fix the issue, identify and remove the intermediate CA certificates from the Trusted Root Certification Authorities certificate store.
  • If you see "Verify challenge returns false" in NDESPlugin.log, check CertificateRegistrationPoint.svclog for errors. For example, you may see a "Signing certificate could not be retrieved" error that resemble the following:
     
    To fix the issue, open Registry Editor, locate the HKLM\SOFTWARE\Microsoft\MicrosoftIntune\NDESConnector registry key, and then check whether the SigningCertificate value exists. 

    If this value doesn’t exist, restart the Intune Connector Service in services.msc, and then check whether the value appears in registry. If the value is still missing, it’s usually because of a network connectivity issue between the IIS/NDES server and the Intune service.
Back to top

Step 4: NDES passes the request to issue the certificate

step 4

In this step, NDES passes the certificate request to the certification authority (CA) and requests the certificate on behalf of the client.
To verify that this step is successful, check the following on the IIS/NDES server:
  1. Look for entries that resemble the following in NDESPlugin.log:
  2. Look for entries that resemble the following in CertificateRegistrationPoint.svclog:

    Log

Troubleshooting

If you don’t see the entries that are listed above, follow these steps:
  1. Look for problems that are logged in CertificateRegistrationPoint.svclog when the certificate registration point verifies the challenge. To do this, check the entries between the following lines:
    • VerifyRequest Started.
    • VerifyRequest Finished with status False
  2. Open the Certification Authority MMC on the CA, and then select Failed Requests to see whether there are any errors. The following is an example:

    Failed requests
  3. Check the application event log on the CA for errors. Usually you can see errors that match those that you see in the Failed Requests in step 2. The following is an example:

    Event log
Back to top

Step 5: The certificate is delivered to the device

step 5

In this step, the certificate is delivered back to the device.
If this step is successful, you will see the issued certificate on the Certification Authority as shown in the following example:

Issued certificate

You will also see the certificate on the user’s device as shown in the following example:
  • Here is the notification:
     
    Notification


    Note If you use Samsung KNOX devices, you won’t be prompted to install certificates.
  • Here is the ROOT certificate that comes down before the SCEP certificate.
    Root CA

    When you check the OMA DM log from the Android device, you can see entries that resemble the following for the installation of the root certificate:
  • Here is the SCEP certificate that comes down to the device:

    SCEP certificate


    SCEP certificate


    When you check the OMADM log from the Android device, you can see entries that resemble the following for the installation of the SCEP certificate:
     

Troubleshooting

The key to troubleshoot this step is identifying and understanding errors that are logged in the OMA DM log. Sometimes the errors are caused by an incorrect configuration.
Back to top

Step 6: The NDES connector reports back to Intune

step 6

In this last step, the NDES Connector reports back to Intune that the certificate has been delivered to the user’s device.
If this step is successful, you will see the following on the IIS/NDES server:
  1. In NDESPlugin.log, you can see entries that resemble the following:
     
  2. In CertificateRegistrationPoint.svclog, you can see entries that resemble the following:

    successful log
  3. In IIS log, you can see an entry that resembles the following for the SCEP process:
     
  4. In NDESConnector.svclog, you can see entries that resemble the following:
    Log
  5. In the %ProgramFiles%\Microsoft Intune\CertificateRequestStatus folder, you can see the Failed, Processing and Succeed folders that contain certificate request status files.
  6. If the certificate request is successfully processed, you can see new files in the Succeed folder as shown in the following example:

    succeed folder


    You can open one of the files to see the type of data that's uploaded to the Intune Service by the NDES Connector, such as CertificateSerialNumber, UserID, DeviceID, and Thumbprint. The following is an example:

    CRS file
In Intune in the Azure portal, you can see that the SCEP certificate profile is successfully deployed to the device.
Device status

Troubleshooting

If you don’t see any new files being created in the Succeed folder, check whether there are any files stuck in the Processing folder. 
If this is the case, verify that the Intune Connector Service is started on the IIS/NDES server, and there are no errors in Ndesconnector.svclog.
Back to top

More Information

If you’re still looking for a solution to a related problem, or you’re looking for more information about Intune, post a question in our Microsoft Intune forum here. Many support engineers, MVPs and members of our development team frequent the forums. So, there’s a good chance that you can find someone with the information you need.
If you want to open a support request with the Microsoft Intune product support team, you can find information on how to do that here:
How to get support for Microsoft Intune
For more information about SCEP certificate profiles in Microsoft Intune, see the following:
For all the latest news, information and tech tips, visit our official Intune blogs:

Comments

Post a Comment

Popular posts from this blog

Service Principal Names (SPNs) SetSPN Syntax (Setspn.exe)

-
Image
Service Principal Names (SPNs) SetSPN Syntax (Setspn.exe) Table of Contents SPN Purpose SPN Format SetSPN Viewing or Checking SPN Registrations SPN Registration Errors Related to SPN Registration or Configuration Manually Registering SPNs Troubleshooting SPN Issues Resolving SPN Registration Issues SPN Lookup Errors Delegation External Articles SPN Purpose A service principal name (SPN) is the name by which a Kerberos client uniquely identifies an instance of a service for a given Kerberos target computer. If you install multiple instances of a service on computers throughout a forest, each instance must have its own SPN. A given service instance can have multiple SPNs if there are multiple names that clients might use for authentication. For example, an SPN always includes the name of the host computer on which the service instance is running, so a service instance might register an SPN for each name or alias of its host. ↑  Return to Top
Read more

altiris software key

-
Image
I think a lot of people, like me, spend a lot of time try finding how to get those download: Latest Symantec workspace Virtualization , SWV 6.1, that is advanced SVS version, is integrated with the Altiris client management suite CMS 7.  (Yes, it was also named "SVS PRO") Notice 1: This package includes the "Wise Virtual Composer", and both x86+x64 versions. Notice 2: This link currently also includes SWS (Streaming) and SWC (Corporate) [please vote my post if you use it ;-] Story : I was thinking only SVS 2.1 (Software Virtualization Solution) was integrated into the "Client Management Suite 7". But this is not the case and SWV 6.1 (Symantec Workspace Virtualization) must not be paid in addition . Free home license : Both SVS 2.1 "light" version & SWV are still free personal use. I suggest you use now the latest SWV 6.4 (That is SWV 6.1 SP7 or following! Yes Symantec do this version naming - vote here also to a
Read more

Azure Fix for "the VM is generalized" start-up error in Microsoft Azure

-
Image
How to fix the below error, it works for when followed the below steps. 1) Go to the "Disks" page in the Azure Portal: 2) Click on the disk that is attached to the generalized VM. 3) Then click "Create Snapshot", and fill in the form: 4) After the snapshot is generated, go to the Disks page, and click "Add". 5) Fill in the "Create managed disk" form, and make sure to select your newly created Snapshot as Source: 6) After the new disk is created, click on it to see details. Then click the button "Create VM": 7) Create the VM as you would normally do. Done!
Read more