Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.

...                       1800 IN  AAAA           ::ffff:                       1800 IN  A                       IN  SRV  10  0   88             IN  SRV  10  0   88


There MUST be an IPv6 AAAA entry - iPhone requires it to work correctly.


AAAA entry may have to be converted to IPv6 format: :::::ffff:102:304

Use web-tool:

Troubleshooting DNS records

To test the DNS settings, you can use the DIG command (built-in to Mac and Linux) or NSLOOKUP on Windows.


Code Block
dig SRV
dig SRV

# You may wish to define the name server to use with dig by using the following command: 
dig SRV

Checking DNS entries with tools

Use Google Toolbox to check the SRV entries:

The result must contain string of type:

;ANSWER 3599 IN SRV 10 0 88

Use NC to check UDP/Kerberos services:

Code Block
nc -u -z 88

# Answer:
#> Connection to port 88 [udp/kerberos] succeeded!

Use nslookup to check the SRV entries:

Code Block
nslookup -q=srv

Non-authoritative answer:	service = 10 0 88


titleCA Requirements (including CloudKDC)...

Client certificates

Key Usage

The client certificate must have a Key Usage field of Digital Signature and Key Encipherment. 

Extended Key Usage

The client certificate must have a EKU id-pkekuoid ( set. iOS devices report this EKU as "Kerberos Client Authentication". The certificate may optionally have the OCSPSigning EKU if OCSP revocation checking is enabled. 

Subject Alternative Names

In addition to the Kerberos-defined format for SAN (which includes a sequence of the principal name and realm name), the CloudKDC KDC server allows a SAN in any of the following additional formats. Italics represent value, plain font is verbatim. Spaces added for clarity.

Code Block
subjectAltName = email : user1
subjectAltName = email :
subjectAltname = otherName :;UTF8 : user2
subjectAltname = otherName :;UTF8 :

NOTE 1: The OID value "" is the standard OID for "User Principal Name" (see

NOTE 2: The CloudKDC KDC server will match a SAN value with the client principal even when the SAN value contains no realm name (which it will not, if supplied by Airwatch). This is non-standard Kerberos behavior, but required for CloudKDC.

For reference, the Kerberos-defined format for SAN is given below, although Airwatch is unlikely to support it and ADCS does not. The principal is stored in a SubjectAltName in the certificate using OtherName. The OID in the type is id-pkinit-san.

  id-pkinit-san OBJECT IDENTIFIER ::= { iso (1) org (3) dod (6) internet (1) security (5) kerberosv5 (2) 2 }

The data part of the OtherName is filled with the following DER encoded ASN.1 structure:

Code Block
KRB5PrincipalName ::= SEQUENCE {
realm [0] Realm,
principalName [1] PrincipalName

Required Matching

Kerberos principal must “match” certificate Subject Alternative Name (SAN)

Identity Manager user must be able to be located based on derived Kerberos principal:


  • Kerberos Principal / SRFC4556 SAN (rare)
  • Match with UPN SAN name (ignore @domain part of SAN)
  • Match with EMAIL SAN username (ignore @domain)

AN Matching (part of certificate validation in KDC)

  • Exact match with

Derived Kerberos Principal / User Matching (part of federation broker in IDM)

  • With UPN SAN that has @, then UPN in IDM is used (name-format = “upn”)
  • Else, if EMAIL SAN, then email in IDM is used (name-format = “email”)
  • Else Kerberos principal is matched with username in IDM (name-format = “”)

Server Certificates

Configure the Microsoft CA to use Subject Alternative Name (SAN) in Certificates:

Code Block
certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc
net start certsvc