SubjectAltName custom policy module in MIM CM

Hi PID_Uri,

Regarding your issue, I'd like to provide some details in a fairly comprehensive explanation, I hope you don't mind reading this long.

The MIM CM SubjectAltName policy module cannot emit a DN-typed SAN. The DLL shipped with MIM CM removed the DirectoryAddress support that existed in the FIM 2010 module. The remaining SAN types are limited to RFC822, UPN, DNS, URI, IP, GUID, and OtherName with fixed OIDs defined inside the module. None of these accommodate an X.500 Distinguished Name structure, and the module does not expose an extensibility point for constructing one. That is why you do not see a field equivalent to DirectoryAddress in the MIM UI.

A DN-formatted SAN requires a SAN type of “directoryName” (GeneralName type 4). Windows CA will only emit a directoryName SAN if the request contains a DER-encoded directoryName element under the SAN extension. Since MIM CM does not generate it and you cannot modify the DLL, you cannot produce it through MIM’s policy module pathway.

The only functional alternatives that keep the system supported and avoid DLL modification are these:

If you embed the SAN yourself before it reaches the CA. MIM CM allows a “request file” to carry fully formed PKCS#10 attributes. If you can inject a correctly encoded directoryName SAN into the request’s Extensions sequence in the PKCS#10 body, the CA will preserve and issue it. Most deployments do not do this because MIM CM normally regenerates the SAN extension from its policy module rules, but if you disable SAN population in the policy module and leave the SAN extension intact in the submitted CSR, the CA will honor it. This requires that your CLM connector generate the ASN.1 itself from the Hebrew DN.

If you bypass the MIM CM SAN controls and use certificate template-level custom SAN from the requester. Windows CA supports “Supply in the request”. MIM CM normally blocks this for SAN unless allowed in the template. If you mark the template to accept SAN from the request and let the MIM request pass through without rewriting the SAN, the CA will issue the directoryName SAN that the requester supplied.

If you introduce an OtherName SAN with an OID you control that contains an ASN.1 structure mirroring a DN. This does not satisfy systems strictly requiring GeneralName type 4, but it passes regulatory checks in environments where the requirement is “DN-structured data” rather than “directoryName SAN type”. The CA and Windows certificate stores will treat it as opaque. This avoids modifying the module but only works if your compliance authority accepts OtherName as equivalent.

If the regulation explicitly demands a true directoryName SAN, the MIM CM policy module cannot produce it. You must either inject the SAN before MIM modifies the CSR or replace the SAN creation path with a component that can emit GeneralName type 4. The MIM CM provided DLL is not capable of generating this structure, and Microsoft never published a supported alternative after retiring the FIM 2010 module.

I hope you find something useful in this answer, and it's appreciated of you to accept it if it helps to some extent. Thanks a lot!

VP