×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

Which identity is ISE meant to place on CSR towards NDES?

Answered Question
Aug 20th, 2012
User Badges:

Hello,


I'm having an issue with the Proxy SCEP function of ISE. I'm basing my config on the BYOD CVD.

I'm able to enroll an iPAD towards my CA, but when checking the issued certificate Common name or SAN, I can only see the NDES service account username/email on the certificate. According to the consulted documentation I was expecting to have a reference to either the mac address of the device to which the certificate was generated for or towards the username that triggered the enrollment request. None of those appear on the visible fields of the certificate.


Nevertheless while debugging the authentication flow, I do see that the Username is the NDES Service Account, but the RADIUS Username is the actual username of the user that triggered the device enrollment.


Can anybody let me know if this is expected behaviour, and how should the certificate be properly generated, and how to configure either the certificate template to this/ISE?


Thanks


Gustavo Novais

Correct Answer by Tarik Admani about 5 years 28 min ago

Gustavo,


I ran into this issue when I was configuring this feature, I didnt get the mac address in the attributes list of the cert, but I was able to modify the template in the screenshot attached so that the certificate generated was the username of the authentication request:


I hope this helps!



Tarik Admani
*Please rate helpful posts*

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Correct Answer
Tarik Admani Mon, 08/20/2012 - 14:08
User Badges:
  • Green, 3000 points or more

Gustavo,


I ran into this issue when I was configuring this feature, I didnt get the mac address in the attributes list of the cert, but I was able to modify the template in the screenshot attached so that the certificate generated was the username of the authentication request:


I hope this helps!



Tarik Admani
*Please rate helpful posts*

Gustavo Novais Mon, 08/20/2012 - 14:20
User Badges:

Excellent Tarik! This did the trick!

I had a few issues in the beginning with 2008 (had to install a hotfix,etc) and had totally overgone this option.

Thanks a lot!


Gustavo Novais

Gustavo Novais Thu, 08/23/2012 - 04:51
User Badges:

Hello,


I'm going through a big issue now.


Actually self provisioned certificates have a different structure than AD-Enrolled certificates.

This means that AD-Enrolled certificates on Corporate laptops are getting their username extracted from the subject UPN/email name.

On the other hand self provisioned devices have the user ID on their Common name, and the subject alternate name has the interface mac-address from which they enrolled from.

I know no functional way to separate authentication rules based on Radius Attributes between self provisioned devices (cert auth should be based on Common name) and corporate enrolled devices (cert Auth based on Subject or Subject Alternate name).

If I change the certificate template  for SPW I go back to having the same user on all self provisioned enrolled certificates...


Does anybody have any suggestion?


Thanks


Gustavo Novais

Tarik Admani Thu, 08/23/2012 - 10:39
User Badges:
  • Green, 3000 points or more

Gustavo,


I assume that the radius username for both certs are different? Does the cert for intenral use the [email protected] format (upn)?


If that is the case the you can create a condition for you authentication rule (under policy elements > conditions) so that the radius username matches @abc.com and then map that to another identity sequence store that uses the attribute you want for internal, but keep your other rule for dot1x users below since this will be more "granular" than your BYOD authentication rule which should point them to the ID sequence you have know.


I set up an example in the lab using the Cert Auth Profile which uses the email attribute, but you can tweak that to your environment.


Attched are the screenshots.


authenticationcondition - creates a filter for the radius username format (you may need to play with this since it doesnt have the "ends with" attribute, I am assuming the "matches" will look for a string pattern)

CAPADInt - creates the certificate auth profile using the attribute in the cert.

AnotherIdenity - sets the sequence so it doesnt break the deployment if users decide to enter their AD credentials using this format also, make sure you sent the condition to continue at the bottom.

MappingtoAuthenRule - is what puts this all together.


Thanks and good luck!!!


Tarik Admani
*Please rate helpful posts*

Gustavo Novais Thu, 08/23/2012 - 12:39
User Badges:

Hi Tarik,


Unfortunately the point is to have the same user bringing in his own laptop/tablet while having his corporate laptop.

This means that the username will be the same, so I can't really do domain manipulations.

The problem is t,hat certificate wise, the self prov certificate has the username iin the common name, and the ad certificate has the username in the subject/San.

Even if I try to match different fields using the CERTIFICATE variable in ISE authc dictionary, it won't get populated until the actual auth has taken place, so it won't work.

I thought about matching the radius calling station id with the registered devices group, but this isn't possible for authC, only for authZ.


I'm stuck... The only alternative I see is to use Peap for byod and tls for internal assets...


Thanks.

Gustavo

Actions

This Discussion

Related Content