Certificate Mapping - Subject Alternate Name

[Legacy User]

Is there any way to map a part of the subject alternate name that isn't in a type "other", in Siteminder/SSO?

I need to map a Subject Alternate Name, type 6 (Uniform Resource Locator) from the cert to LDAP.  That appears to be the only field holding a useful identifier for the certificates.

It looks like the OID method only applies to type 0, the only specific parts of the subject alternate nameI see mentioned are RFC822Name, PrincipalName and FASC-N, and I haven't found many other applicable references.

[Adam Rusniak]

Erin,

 

 

It does seem like an odd attribute to map to for a user certificate though.... This is the only unique value that matches a value in your LDAP?

Thanks,

Adam

[Legacy User]

As far as I can tell, the OID reference for Subject Alt. Name fields only refers to type 0 (OtherName) values.  That was what I originally thought I could do, until I went to look for an OID...

It seems to be the only unique value at all - I couldn't assume first/last name are unique.  Nothing in that list of mappable values seems likely to work.

[Adam Rusniak]

Erin,

 

Can you test the mapping the way I mentioned to rule it out as a valid possibility?

 

Also, my question to your PKI administrator is, why are they storing User Unique attributes on the Uniform Resource Locator certificate field? Can you post an example of your Certificate structure (masking sensitive data) so we can we what you are working with.

 

openssl x509 -in userCert.cer -noout -text

 

or screen shots from a Windows client certificate view.

 

 

thanks,

Adam

[Adam Rusniak]

Erin,

 

The following is from the ietf.org page referencing the requirements for certificate structure specifically the Subject Alt Name [6]

 

When the subjectAltName extension contains a URI, the name MUST be

  stored in the uniformResourceIdentifier (an IA5String). The name

  MUST NOT be a relative URI, and it MUST follow the URI syntax and

  encoding rules specified in [RFC3986]. The name MUST include both a

  scheme (e.g., "http" or "ftp") and a scheme-specific-part. URIs that

  include an authority ([RFC3986], Section 3.2) MUST include a fully

  qualified domain name or IP address as the host. Rules for encoding

  Internationalized Resource Identifiers (IRIs) are specified in

   Section 7.4.

RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile

 

I guess my question then to you would be, if the certificate is compliant with IETF standards, how can you have a "user specific distinguished attribute" stored in this field on your certificate? It seems to state that field MUST contain FQDN, with http or ftp or IP address etc.

 

This is my thinking for why the Advanced certificate module does not make reference to mapping to this field.

 

Thanks,

 

Adam

[Legacy User]

Well, it's unlikely I'd get anyone to change a certificate format that isn't ours, and is used by many others, so it's rather a moot point, whether or not it is a good idea, though it looks like there are similar examples in the 3986 link, so I'm not even sure it does go against those standards.  Either way, as CA seems to have implemented other fields for similar government standard formats, it seemed quite possible someone had solved this.  I was hoping I'd overlooked an option or work around - either in the mappings or some other way to get the userid or identifying field to Siteminder - just any way that I could log in someone with a cert if I could not use the fields specifically mentioned in the mapping documentation.  I don't see how others are implementing these cards, but I know other places have...  just can't find how.  Almost any other field it seems I could use an OID for, but not that one unfortunately.

[Adam Rusniak]

Erin,

 

Without being able to see the current structure or information coming in on your certificates it will be very difficult to assist further. If your CA chooses to impose custom information going against the IETF standards, then it can't be expected for the CA software to accommodate all of these custom changes.

 

If you can give more information I would be more then happy to continue helping and doing research on my end.

 

Thanks,

[Rick_Siek]

First of all, I assume you are referring to the Advanced Certificate Authentication scheme (SmX509CertAuth) that I wrote, and not the built-in SiteMinder certificate authentication scheme?

 

Is the subjectAltName URI really unique to a single user for the Certificate Authority?

What about using the certificate SerialNumber?If the subjectAltName URI really is unique and and you can't use any other field, then you should be able to access it via the %{(oidVal).(oidVal2)} syntax.

It would be helpful if you could provide a sample test certificate from your CA that has the same fields filled in as the ones you expect to see.

You can contact me directly at [e-mail].

[Legacy User]

Yes, I believe that's the SmX509CertAuth. 

%{(oidVal).(oidVal2)}  had definitely occurred to me... it's why I thought I could pull about anything and did not worry until I tried it - I wasn't certain how to reference the field but had not seen it as a problem until now.  However, I see an oidVal for "SubjectAltName"... but not for that subfield in the tools I've tried.

I will email.  Thanks.

[Rick_Siek]

It turns out that the SubjectAltName URL subfield (choice 6) does not have an OID, so the URL subfield cannot currently be used for mapping certificates to user accounts in a SiteMinder user store. It would take an enhancement to SmX509CertAuth ( aka Advanced Certificate Authentication, ACA) to provide this capability.

[Adam Rusniak]

Richard,

 

Am I misunderstanding the RFC3986 Section 3.2 that I mentioned above? I can't image what User specific information would be stored in a field designated to hold FQDN's and IP addresses. Can you help me understand? Is it even a valid enhancement idea if it goes against the IETF standards?

 

Thanks,

Adam

[Rick_Siek]

I think you may not be appreciating the full flexibility of the URI syntax. I know I tend to always associate URI with web addresses, but the URI syntax itself is much more general.  Web address URIs are just one "scheme" supported by the URI syntax, and each scheme has its own rules.

If you go to Uniform Resource Names (URN) Namespaces

you will find that the urn scheme has a uuid namespace, among many others.  The test cert that Erin supplied to me uses the following syntax:

     urn:uuid:uuidValue

So from my, admittedly brief, research I would say that the value that Erin is trying to use is valid. The RFC you mention even uses a similar example:

     urn:example:animal:ferret:nose

 

Rick

[Adam Rusniak]

Thank you Richard for clarifying that for me. Guess it just seemed an odd mapping, I will do some more research on the rfc.

 

Appreciate it,

 

Adam

[Brett Carroll]

I am evaluating the SmX509CertAuth (Advanced Certificate Authentication) AuthScheme to pull the FASC-N, but am getting errors.

 

I have tried everything I can think of (based on the SmX509CertAuth documention), everything I have tried results in the same error message in smps.log

 

Here is the error I am seeing:

[26964/23][Tue May 17 2016 10:52:42][SmAuthUser.cpp:691][ERROR][sm-Server-02740] SmX509CertAuth:GetExtensionsObject:Name type: 6 is not a recognized Subject Alternate Name Type!

 

Here are the expressions I have tried:
%{Alt.FASC-N}
%{Alt.FASC-N.AC}
%{(2.16.840.1.101.3.6.6)}

[Adam Rusniak]

Hi Brett,

 

I assume you have the Policy Server trace logging set high enough to see all of the information being pulled off of the certificate. If you are on a Linux O/S for the policy server can you execute

 

tail -f smtracedefault.log > traceCert.txt

If you are on Windows then you will just need to view the trace log after the authentication attempt.

 

Then clear your browser cache, cookies and SSL state information and make the authentication attempt again. After you receive the failure stop the tail on the trace log. Can you review through the log and look at every attribute that the Policy Server pulled off of the certificate and see if you locate the value in any of them that you are attempting to use to identify your certificate user. I have also seen that Name Type 6 Error in my policy server logs, but I believe this was caused when the certificate has a value in that type 6 field and the policy server can not use it. This doesn't mean though your particular value is not actually stored in another field and we just need to see which one that is.

 

Let me know, thanks,

Adam

[Rick_Siek]

Brett,

 

If you send me the smtracedefault.log log snippet of the failed authentication transaction that Adam suggested you collect and send it to me ([e-mail]), I will take a look at it and try to determine what is wrong. The mappings you tried are valid. By the way, what version of ACA are you using?

 

Rick

[Brett Carroll]

I am using 3.7.3 with r12.52

(my Policy Server is Solaris, so the Linux logic applies...)

 

It appears that there is another issue happening that is throwing me off.

 

The Policy Server is disregarding the search base configured in the UserDirectory and instead using the IssuerDN as the search base.  Is there any way to change this behavior?

 

Example:
The UserDirectory has "ou=department,o=company,c=us" configured as the search base.
My Certificate is issued from: ou=ca1,ou=certificate authorities, ou=department,o=company,c=us
The user information I need to map this certificate to is stored in: "ou=people,ou=department,o=company,c=us"

 

The LDAP Server logs indicate that SiteMinder is using IssuerDN as the base for the LDAP search.

[17/May/2016:13:42:37 -0400] - SERVER_OP  - INFO  - conn=19722500 op=4 SEARCH base="ou=ca1,ou=certification authorities,ou=department,o=company,c=us" scope=2 filter="(&(|(objectclass=organizationalPerson)(objectclass=inetOrgPerson)(objectclass=organization)(objectclass=organizationalUnit)(objectclass=groupOfNames)(objectclass=groupOfUniqueNames)(objectclass=group))(serialnumber=403043))" attrs="objectclass " s_msgid=14 s_conn=tedsdsm2 (write):579378

 

In the above example, I created a Custom Certificate Mapping Expression to pull the SerialNumber attribute out (part of the SubjectDN, not the cert serialnumber) and map that to an LDAP attribute that is also named serialnumber using {DN.SerialNumber}.
My subject DN syntax is "cn=First M. Last + SerialNumber=123456,ou=people,ou=department,o=company,c=us"

[Adam Rusniak]

Brett,

 

So in your test custom example using the serial number. If you take the LDAP search expression to your User Directory on the View Contents Screen and switch the filter to LDAP expression.

Using the following expression as the value for your search expression:

(&(|(objectclass=organizationalPerson)(objectclass=inetOrgPerson)(objectclass=organization)(objectclass=organizationalUnit)(objectclass=groupOfNames)(objectclass=groupOfUniqueNames)(objectclass=group))(serialnumber=403043))

 

Does this properly disambiguate to the user you are looking for? I am trying to remove a few variables in the equation.

 

Thanks,

Adam

[Brett Carroll]

If I remove the outer parenthesis, the search works from the UserDirectory View Contents screen.
&(|(objectclass=organizationalPerson)(objectclass=inetOrgPerson)(objectclass=organization)(objectclass=organizationalUnit)(objectclass=groupOfNames)(objectclass=groupOfUniqueNames)(objectclass=group))(serialnumber=403043)

[Adam Rusniak]

Alright so it finds the user that way removing the outer parenthesis. When you attempt to authenticate the user though the policy server is not returning a user correct? Even with this new custom attribute you are testing with.

 

Am I correct that you are testing two use cases? One with the unique attritbute stored in the FASC-N of certificate and a separate test use case storing the custom attribute serial number of user in the subject DN?

[Brett Carroll]

From my research, the Policy Server is not returning a user because the search base is not correct.  The SmX509CertAuth module seems to be overriding the SearchBase configured in the UserDirectory with the IssuerDN.

 

The use case is:
1. Map the SerialNumber attribute from the DN to a serialnumber attribute in LDAP (to find the user).

     - This part is working aside form the searchbase being incorrect, using the CertMap directive in SmX509CertAuthSettings.cfg

     - CertMap=IssuerDN^serialnumber=%{DN.SerialNumber}
2. Make the FASC-N of the Certificate available as an attribute that can be added to a SAML Assertion (Session Variable, user attribute, etc...)

[Adam Rusniak]

Brett,

 

Sorry for my delay in response to this post. Can you test the Advanced Auth scheme without using the .cfg file for your certificate mapping? To do this you will need to create an Authentication Scheme with the Authentication Scheme type of X509 Client Cert Template. Set the appropriate scheme set up to call your web server handling the certificate require and the target will be /siteminderagent/cert/smgetcred.scc.

 

You will change the Library name to call the Advanced Auth module and make sure the parameter is exactly:   SmX509CertAuth

 

Your parameter will then read - https://fqdnofwebserver/siteminderagent/cert/smgetcred.scc?cert

 

Make sure to have your certificate mapping created on the AdminUI for the Issuer DN of your certificate. This will then not use the .cfg file to remove that variable and will use the built in policy server certificate mapping still calling the advanced Library.

 

Please post back and let me know your results.

Thanks,

Adam

[Brett Carroll]

That is what I was doing initially, not using a customized .cfg file and just using the Certificate Mapping in the AdminUI.

I spoke with Rick Siek offline and it sounds like I need to open a support case to have them look deeper into the issue, since the behavior I am seeing is not at all what the module should be doing.

 

The Certificate Mapping is working correctly, the issue now is that when the Policy Server searches the LDAP UserDirectory for the user entry, the search base is incorrect, so no user is ever found.

[Adam Rusniak]

Brett,

 

Please keep us updated on the progress of this. I would like to hear a resolution or help further if I can.

 

Thank you,

Adam

[Brett Carroll]

Well we figured out part of the issue.  The incorrect searchbase was coming from the CRL Checking part of the AdminUI CertMapping configuration.  At one point we were doing CRL Checking in SiteMinder and had a UserDirectory configured with the IssuerDN as the Root of that User Directory.  CRL Checking was disabled in the AdminUI CertMapping config for this particular Issuing CA, but for some reason SiteMinder was linking to the UserDirectory specified in the CRL Checking  config (even though is was disabled, and has no user entries in it).   I changed the CRL Checking config to use a UserDirectory that contains user entries, enabled CRL Checking, saved the config, then disabled CRL Checking, and saved the config again.  This fixed the weird search base issue.

 

I now have a different/similar issue though.  The search base is no longer the IssuerDN, but now it is the searchbase of one of our other UserDirectories, not the UserDirectory specified in the Policy Domain.  I am hoping we are not running into some sort of Policy Store corruption, but we have been hit with that in the past so I can't rule that out.