Allow ISE captive portal DNS entry on outside DNS.

[kshah2589]

Hello,

We are having ISE for EAP/TACACS authentication and, hosted internally in our datacenter.

Now we have configured BYOD captive portal that tied to AZURE SAML authentication, the current captive portal redirect URL from ISE has prepended the node name of ISE server within the URL. However, our requirements are to use external DNS servers for this particular scenario in which captive portal URL resolve to internal IP by external DNS server as well the captive portal will use different hostname and domain name. I would like to know what steps we need to follow to achieve the same goal.

[Arne Bier]

I just tried this in the lab and had to remind myself of the process In ISE 3.2 I always get 2 CSRs if I tick both node boxes for EAP or Portal cert. Since we only want to create ONE portal cert, we can't tick both boxes.

You must always at least one node. But you do not have to tick all of them. By putting a tick in the box, you're essentially telling ISE where to the private key during the CSR creation. So here's my advice for the portal cert CSR:

Tick only one of the node tick boxes (doesn't matter which one)

 In the Common Name (CN) field, remove the $FQDN and type in something like portal.mycompany.com (it doesn't have to be a valid FQDN). If it makes you feel better, pick a valid FQDN here (e.g. portal1.mycompany.com) - but it's not required.

Enter all the rest of the fields, and ensure the SAN contains DNS:portal1.mycompany.com and DNS:portal2.mycompany.com.

Export the single CSR and get it signed by CA. Then bind the cert back to this CSR. You will have only one ISE node with the portal cert. You then export that cert with its private key, and import it into the other ISE node. When ISE asks for a password, you can make up any password you like - its only purpose is to protect the private key during export/import stage.

[kshah2589]

Thank you so much for getting back to me. we are running ISE version 3.0.0.458 and not ISE 3.2, do you still recommend me to follow the same steps as you mentioned above because when we did same thing for "EAP Authentication" couple of days back it generated only one CSR(PEM file) which contains both SAN value?

Regards,

Kunal

[Arne Bier]

I would still use the same method I outline above, to create the portal certificate.

I am pretty sure that even in ISE 3.0, if you create a CSR for EAP, and tick both ISE nodes, then it will create two certs. The SAN for EAP certs is not important - I always put a DNS SAN, but I think the software that drives EAP clients and supplicants only looks at the Subject CN (if asked to validate the "server name") 

[kshah2589]

Thanks Arne Bier, I will follow the same steps as outlined above for portal cert. 

I have confusion with EAP authentication certificate, you mean the supplicant software doesn't look SAN and only look for subject CN? if it's like that then we need to generate second CSR and send it to CA or export that cert with its private key, and import it into the other ISE node will work?

[Arne Bier]

You won't need another cert for the ISE EAP function. 802.1X supplicants do not inspect the SAN entry of the Server Certificate. They might look at the Subject Common Name if told to do so (in Windows native supplicant there is a text entry box, in which you can enter a string, which is the Subject Common Name that you expect the Server to have) - supplicants mostly care about whether or not they cryptographically trust the server with whom they are communicating. This means, having the necessary Root CA and intermediate CA certs on the supplicant is usually all that matters. 

[kshah2589]

Got it, thank you so much for great explanation.

[kshah2589]

Hello,

We have ordered multi-SAN certificate from digicert (portal1.abc.com and portal2.abc.com) and uploaded same certificate to our both ISE node but the issue we are facing is that when user try to connect to ISE node in east coast with dns entry as portal1.abc.com it throws cert error but there is no error if they try to connect ISE node in west coast with dns entry as portal2.abc.com.

Any help on this issue is appreciated.

[Arne Bier]

Please remind me what you're trying to accomplish?  If you're doing portal redirection, then you must provide screenshots here of your ISE Authorization Rules. You'll need two Authorization Profiles (results), each configured with the correct URL that points to the PSN that is processing the request.  The portal is the same, but the URL is specific to the PSN that is handling the MAB request. This logic applies to guest and BYOD portals, when there are two PSNs involved. 

[kshah2589]

Yes we are doing portal redirection with Azure SAML authentication.

we have two authorization profiles one for each URL and two authorization rules one for each PSN with corresponding authorization profiles. We are using multi-SAN certificate ((portal1.abc.com and portal2.abc.com), but the issue is one gives certificate error whereas other doesn't give an error. what could be the reason?

Let me know if you have any questions.

[Arne Bier]

There should be no issue with this, as long as the DNS entries correspond to the correct PSN - e.g.

portal1.abc.com -> IP address of PSN1

portal2.abc.com - IP address of PSN2

And when the client performs a DNS query for each portal, do they resolve to the correct PSN's IP address?

I can't see your ISE config but I assume it's correct as described.

What is the error you are getting?

[kshah2589]

1). Yes, we have DNS entries correspond to the each PSN. It is also resolves to correct IP addresses when performs DNS query.

2). What else you want me to check in ISE configuration?

3). When user try to reach portal1.abc.com they get browser warning "Your connection is not private" but no error when try to reach portal2.abc.com

[Arne Bier]

I find that hard evidence (screen shots) is better than written bullet point statements/assertions.

Check the System cert for PSN2 - do you see the portal cert installed with the Certificate Tag that matches that of the Portal?

Reproduce the issue and show screenshot of the offending cert (from the browser's point of view - click on the icon in the URL and examine the cert that ISE returns to the browser)

Then examine (show screenshot) of the Authorization Profile that ISE returned to the WLC - ensure that the Calling-Station-ID is the MAC address of the client that's having the issue. If the Cisco AVPair containing the URL is correct, and the client is resolving the FQDN correctly, then there should be no error.  UNLESS, the client doesn't have the CA Chain of the public CA installed - we trust that operating systems have this installed. If it's Firefox browser then be extra careful because it doesn't use the operating system CA (unless they changed that recently)

If there is an issue on the PSN webserver (wrong cert applied to the PSN) then you should see this manifested on the client - obviously the web server is succeeding in creating a TLS connection and is exchanging the cert during Server-Hello phase.

 If the ISE config is 100% correct, then you might want to stop application ise on PSN2 and reload the box. There is a possibility that this might fix it.

[kshah2589]

Thanks Arne Bier. 

Following is our observation after multiple testing.

1). Adding intermediate certificate to browser certificate store resolves the issue(no certificate warning) for portal1.abc.com but the confusion is why portal2.abc.com work perfect without intermediate certificate.

Let me know if you have some suggestions.

[Arne Bier]

Have you installed the public CA Root and Intermediate/Issuing CA certificates in ISE as well?

Perhaps a PSN reload is required.

[kshah2589]

yes we have installed both root and intermediate certificates in ISE.

Let me reload the PSN and see if resolves the issue.