Wednesday, December 18, 2019

Android Enterprise Dedicated Devices and SCEP

Hello Everyone! 

Recently SCEP certificate authentication was released for Intune with Android Enterprise devices. This means both COPE and Kiosk devices or whatever they are calling them these days.

I just finished setting this up for a customer and let me tell you there were some challenges. I don't have any screenshots of the issues but I just want to run down a list of gotchas that we ran into to help you do the same. Once we had all other platforms working (iOS, Android Legacy, Android Work Profile) we thought Android Fully Managed would be a simple reconfig. It was not. 

1.) Deploy the sub cert out with the root, this should always be done in my opinion.

2.) Make sure the devices have a Compliance Policy assigned. Our kiosk devices originally were marked as non compliant because we did not have one assigned as they were already so locked down (this is just the way the customer had their environment configured). We were seeing the SCEP, Root, and Sub certs stuck as 'Pending'. This went on for a day or so until we got Microsoft Support on the line who suggested the Compliance policy as a general fix. He eluded that this is something he does as a baseline because of, well, just Intune being Intune. 

3.) I have done iOS kiosk devices in the past that are without user affinity and I have used the DNS attribute in the same name historically. You can not do that with Android from what I have found. The WiFi settings on the device itself will not recognize a certificate unless it has the UPN in the SAN name. It will never even attempt a connection if you give it a DNS SAN cert.

4.) This could be just coincidence but we supplied an external identity in our WiFi profile as well. We just used a generic name of Android Kiosk and once it actually authenticated the identity changed to {{serialnumber}}@domain.com like it was supposed to

5.) We had some issues with time outs attempting to fetch the SCEP certs and WiFi policies. We were able to solve this by syncing from both the Intune app and the built in Android Device Policy app. My running theory on this (and im sure I am going to butcher it) is that the Intune certificate connector doesn't look at any Google API syncs from the Device Policy app. So when you sync from there you receive the SCEP profile, you hit IIS, hit the connector, and then it just sits waiting for the Intune sync to validate and eventually times out. Moral of the story is to sync from both the Intune App and the Device Policy App.

This is all also assuming you have a healthy SCEP and PKI infra underneath everything which can be a task itself!

These are all just some thoughts from someone who has spent far too long poking at SCEP. 

Send help in the form of miniature paints and Chipotle.

Best of luck!


8 comments:

  1. Having the same issue. I can push root cert to A4W but stays as pending for Kiosk (Dedicated) and Fully Managed builds. Driving me nuts :-(

    ReplyDelete
  2. could you possibly provide more information around the parameters used in the Certificate Generation? What was used for the certificate SUBJECT? just CN={{Device_Serial}}?

    Did you create a device account in Active Directory for each device? What type of account was required? generic user account?

    ReplyDelete
    Replies
    1. Hello Stephen,

      The certs are not tied to anything in local AD. You supply the paramaters in the Intune cert profile (subject name and SAN name).

      As far as what I put in the fields I normally use (or whatever it actually is) {{AzureADDeviceID}}@domain.com with the domain.com part being static. I will usually put the same info in the SAN field.

      Hopefully that helps some, if not let me know

      Delete
    2. Thanks for the response, Sorry What I meant with the AD is the authentication that radius performs with AD from the received ID during the EAP authentication, i.e. if it exists in AD then radius approves connection. I have got things working with a fixed ID for EAP-TLS, but finding that if the outer ID and cert UPN differ it fails to AUTH as I want to use the {{AAD_Device_Id}}@xyz.com in my CERT UPN and this gets generated correctly, however connection fails when the outer ID differs from the UPN, as the outer ID fields wont allow dynamic generation of the name like the certificate profiles does using {{AAD_Device_Id}}

      Delete
    3. The outer identity, in say a wifi profile, shouldnt have to match the values on a cert. A lot of times Ive just used Android@domain.com.

      To me it sounds like your radius is trying to do a check for some value or object that exists with internal AD and that just wont work. I usually tell my auth system, lets say CISCO ISE as an example, to check the cert and if this cert has the correct chain from my internal PKI and has a SAN name of DNS that ends in Domain.com (basically *@domain.com is what its checking) then to allow access.

      I am no network guy by any stretch of the imagination so I may be off base here.

      Delete
  3. Thanks for the description, I have a ticket opened with Microsoft to resolve the outer auth requirement that I'm currently seeing.

    ReplyDelete
  4. hi stephen, did u get any solution here as i face the same issue

    ReplyDelete
    Replies
    1. Yes I did, the outer identity needs to be identical to that of the identity in the Device certificate UPN, this is how Microsoft works around an Android limitation (as told by support) only problem with this solution is the WIFI profile outer identity is not dynamic like the UPN in the device certificate so is fixed.

      Delete