Role mapping using client certificate attribute fails

[jeronimo]

Hi,

I'm having trouble authenticating a client certificate. Everything works up to the role mapping of the realm. I am trying to use an attribute called SERIALNUMBER in the Subject field of the client certificate.

If I configure role mapping to map a certificate attribute to a certain role it fails. (certificate attribute "SERIALNUMBER" is  "..." --> assign these roles "Users")

If instead I use the username generated by the username template from the authentication server (certificate server) then it works.

Why can't I use the certificate attribute directly?

The second problem is I tried using policy tracing for "Role Mapping", but it does not log anything specific related to role mapping.

Info     PTR10103     2017/11/30 01:44:16 - PULSE2 - [192.168.1.102] - admin(Admin Users)[.Administrators] - :xRealm - Policy Tracing turned on
Info     PTR23331     2017/11/30 01:44:39 - PULSE2 - [192.168.1.102] - System(xRealm)[] - Sign-in browser = "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0"
Info     PTR23331     2017/11/30 01:44:39 - PULSE2 - [192.168.1.102] - System(xRealm)[] - Sign-in Perferred Language = "en"
Info     PTR23331     2017/11/30 01:44:39 - PULSE2 - [192.168.1.102] - System(xRealm)[] - Sign-in URL = "*/"
Info     PTR23331     2017/11/30 01:44:39 - PULSE2 - [192.168.1.102] - System(xRealm)[] - Sign-in host name = "192.168.1.102"
Info     PTR23331     2017/11/30 01:44:39 - PULSE2 - [192.168.1.102] - System(xRealm)[] - Sign-in host address = "192.168.1.102"
Info     PTR23331     2017/11/30 01:44:39 - PULSE2 - [192.168.1.102] - System(xRealm)[] - Sign-in network interface = "internal"
Info     PTR23338     2017/11/30 01:44:39 - PULSE2 - [192.168.1.102] - System(xRealm)[] - Requesting client certificate as required
Info     PTR23329     2017/11/30 01:44:47 - PULSE2 - [192.168.1.102] - System(xRealm)[] - Resuming sign-in process
Info     PTR23386     2017/11/30 01:44:47 - PULSE2 - [192.168.1.102] - System(xRealm)[] - Created user name "LT12345" from template "LT<certDN.serialNumber>"
Info     PTR10104     2017/11/30 01:45:19 - PULSE2 - [192.168.1.102] - admin(Admin Users)[.Administrators] - :xRealm - Policy Tracing turned off 

Any idea?

Thanks.

 

[jeronimo]

Answer to question #2

In order for complete authentication trace to work as expected you have to:
    * Provide the realm to trace
    * Provide the IP address in order to see PRE-LOGIN/USERNAME stuff happening (ONLY THAT!)
    * Provide the username in order to see what happens later

If you don't provide a username and ONLY an IP address you will see nothing past login and vice-versa (no IP = no pre-login data, obviously).

Answer to question #1

Policy trace shows:

No match on rule 'certAttr.certDn.serialNumber = '1030xxxxxxx84'' 

This should be "certDn.serialNumber" and not "certAttr.certDn.serialNumber".

So it appears you can only check attributes within certAttr and not within the subject.

Feature or bug?

[jeronimo]

Tried contacting support about this. I have the feeling they just can't understand what you are telling them, much like every other first-level helpdesk. They provided workarounds like "use the username template" or "use a custom expression". That's not wrong, however I'd really love to know why things are as they are (certificate attribute matching does not work for subject attributes, what's so hard to understand about that?). I gave up. Too bad. (Well, Fortinet is worse.)

BTW I don't think it's very professional to ask for the private key of my certificate in order to test in the lab... (ROFL on that one)

[zanyterp]

I'm sorry to hear that they asked for that (rather than a sample for a test user that you can immediately expire).
I believe that certAttr.* is always used for certificate checks.
Is the serial number a standard attribute that I should be able to enable on my CA for testing this?

[Sad Urchin]

I used the following in custom expressions, and it worked:

certAttr.serialNumber = "02"

Request you to please try this and check

[jeronimo]

---

@Sad Urchinwrote:

I used the following in custom expressions, and it worked:

 certAttr.serialNumber = "02"

 Request you to please try this and check

---

Yep, no news there