Some clichés are true. One I found confirmed often is about how technologies are adopted within organizations: One manager meets another manager at a conference / business meeting / CIO event. Manager X show off the latest gadget and/or brags about presents a case-study of successful implementation of Y.
Another manager becomes jealous inspired, and after returning home he immediately calls upon his poor subordinates and have them implement Y – absolutely, positively, ASAP.
I suspect that this is the preferred diffusion mechanism for implementing SAP at any kind of organization or for the outsourcing hype (probably also the insourcing-again movement that followed it).
And I definitely know this works that way for iSomething such as iPhones and iPads. Even if iSomething might be not the officially supported standard. But no matter how standardized IT and processes are – there is always something like VIP support. I do remember vividly how I was one told that we (the IT guys) should not be so overly obliging when helping users – unless I (the top manager) need something.
So trying to help those managers is the root cause for having to solve a nice puzzle: iThings need to have access to the network and thus often need digital certificates. Don’t tell me that certificates might not be the perfect solution – I know that. But working in some sort of corporate setting you are often not in the position to bring up these deep philosophical questions again and again, so let’s focus on solving the puzzle:
[Technical stuff – I am trying a new format to serve different audiences here]
Certificates for Apple iPhone 802.1x / EAP-TLS WLAN Logon
The following is an environment you would encounter rather frequently: Computer and user accounts are managed in Microsoft Active Directory – providing both Kerberos authentication infrastructure and LDAP directory. Access to Wireless LAN is handled by RADIUS authentication using Windows Network Protection Server, and client certificates are mandatory as per RADIUS policies.
You could require 802.1x to be done by either user accounts and/or machine accounts (though it is a common misunderstanding that in this way you can enforce a logon by 1) the computer account and then 2) the user account at the same machine.) I am now assuming that computers (only) are authenticated. This the iDevice needs to present itself as a computer to the logon servers.
Certificates contain lots of fields, and standards either don’t enforce clearly what should go into those fields and/or applications interpret standards in weird ways. Thus the pragmatic approach is to tinker and test!
This is the certificate design that works for iPhones according to my experience:
- We need a ‘shadow account’ in Active Directory whose properties will match fields in the certificates. Two LDAP attributes needto be set
- dnsHostName: machine.domain.com
This is going to be mapped onto the DNS name in the Subject Alternative Name of the certificate. - servicePrincipalNames: HOST/machine.domain.com
This makes the shadow account a happy member of the Kerberos realm.
According to my tests, the creation of an additional name mapping – as recommended here – is not required. We are using Active Directory default mapping here – DNS machine names work just as user’s UPNs (User Principal Name – the logon name in user@dmain syntax. See e.g. Figure 21 – Certificate Processing Logic – in this white paper for details.)
- dnsHostName: machine.domain.com
- Extensions and fields in the certificate
- Subject Alternative Name: machine.domain.com (mapped to the DNS name dnsHostName in AD)
- Subject CN: host/machine.domain.com. This is different from Windows computers – as far as I understood what’s going on from RADIUS logging the Apple 802.1x client sends the string just as it appears in the CN. Windows clients would add the prefix host/ automatically.
- If this is a Windows Enterprise PKI: Copy the default template Workstation Authentication, and configure the Subject Name as to be submitted with the Request. It is not required (and dangerous) to configure the CA needs to accept custom SANs via enabling the EDITF_ATTRIBUTESUBJECTALTNAME2 flag. – unless you insist on adding those SANs in the /certsrv web application. Keys need to be configured as exportable to carry them over to the iDevice.
- Subject Alternative Name: machine.domain.com (mapped to the DNS name dnsHostName in AD)
- Create the key, request and certificate on a dedicated enrollment machine. Note that this should be done in the context of the user rather than the local machine. Certificates/key could be transported to another machines as PKCS#12 (PFX files).
- Import the key and certificate to the iPhone using the iPhone Configuration Manager – this tools allows for exporting directly from the current user’s store. So if the user does not enroll for those certificates himself (which makes sense as the enrollment procedure is somewhat special, given the custom names), the PFX files would be first imported to the user’s store and then exported from there to the iPhone.
The point I like to stress in relation to certificates is that logon against AD is based on matching strings – containing the DNS names – not on a binary comparison of a file presented by the client versus a certificate file in the directory.
I have encountered that misconception often as there is an attribute in AD – userCertificate – that is actually designed for holding users’ (or machines’) certificates. But this is more of a Alice-tries-to-get-Bob’s-public-key-phonebook-style attribute, and it is not intended to be used for authentication but rather for encryption – Outlook is searching for S/MIME e-mail recipients’ public keys there. Disclaimer: I cannot vouch for any custom application that may exist.
Authentication is secure nonetheless as the issuing CA’s certificate needs to be present in a special LDAP object, the so-called NTAuth object in Active Directory’s Configuration Container, and per default it can only be edited by Enterprise Admins – the ‘root admins’ of AD. In addition you have to configure the CA for accepting arbitrary SANs in requests.
_____
Further reading – why this can be dangerous.
_____
Obligatory illustration added by a time-traveler from the future – matching the post, sort of:
Leave a Reply