Where to configure public FQDN for Guest users. In Cisco ISE or WLC?

[iran]

Hi, 
I have a doubt.

I am using Cisco ISE guest portal to register Guest users.
I have configured a public FQDN to assign to guest portal, since Guest will not have access to internal DNS.

My question is:
Where should I insert/configure this FQDN, in the WLC or in Cisco ISE?

[Flavio Miranda · Accepted solution]

Hi @iran  

 You need to add it to your DNS server first as clients devices will  try to resolve your FQDN to IP in order to reach the Portal. 

And you need to add it on ISE if you are going to use CWA or on the WLC if you are going to use LWA. 

CWA - Central web authentication - The ISE push the portal to cilents via RADIUS attributes.

LWA - WLC handles the porta, and use ISE to validate the users database. 

[iran]

Hi,

Thank you for your reply.
Yes, I already created the DNS record.

I am using CWA.
Should I configure here the FQDN? And is the only place where should I add FQDN configurations?

Please let me know if my understanding is correct.

[Flavio Miranda]

Exactly!

[Aref Alsouqi]

How many PSNs do you have? if more than one, then you would need to create an authorization profile and an authorization rule for each PSN to ensure the session is maintained on the same PSN that started it. In that case you would have multiple FQDNs for example guest1.mycompany.com and guest2.mycompany.com, each FQDN would be resolving to a specific PSN. A better way to do this would be to create an authorization profile without specifying the FQDN or the IP, and then creating a single authorization rule for redirection, and finally create IP aliases on the PSNs via CLI with the command "ip host < IP address > < FQDN >". Also, the DNS entries you created would need to be configured with ISE private IP addresses of the PSN unless you have a NAT device in the middle. That is the case even if you dedicate an interface on ISE for the guest portal.

[iran]

Basically we have 5 PSN nodes.
Here are the the authorizations rules:
I have 6, one for Guest flow and 5 for redirect to the Guest portal

And I have 5 Authorizations Profiles:

My questions was, where should I put the FQDN? Is there right?

I have 5 publics FQDNs, one per PSN.

I sent the image as attached also, I dont know why my images lost quality.

Please let me know if my approach makes sense

[Charlie Moreton]

Check out our ISE Guest Access Prescriptive Deployment Guide

[halvespatwer · Accepted solution]

The public FQDN for guest users can be configured in either Cisco ISE or the WLC. However, there are some pros and cons to each approach.

• Cisco ISE: Configuring the FQDN in ISE allows you to take advantage of ISE's centralized authentication and authorization capabilities. This can be helpful if you have a large number of guest users or if you need to enforce specific policies for guest access. However, configuring the FQDN in ISE can be more complex than configuring it in the WLC.
• WLC: Configuring the FQDN in the WLC is simpler than configuring it in ISE. However, you will not be able to take advantage of ISE's centralized authentication and authorization capabilities.

In general, if you need to take advantage of ISE's centralized authentication and authorization capabilities, then you should configure the FQDN in ISE. However, if you do not need these capabilities or if you need to simplify the configuration, then you can configure the FQDN in the WLC.

As an example, let's say you want to configure a smoker so that it can only be accessed by guests who have been authenticated through Cisco ISE. In this case, you would need to configure the FQDN for the smoker in ISE. This would allow you to ensure that only authenticated guests can access the smoker, and it would also allow you to enforce specific policies for guest access, such as limiting the amount of time that guests can use the smoker.

On the other hand, if you did not need to take advantage of ISE's centralized authentication and authorization capabilities, then you could configure the FQDN for the smoker in the WLC. This would simplify the configuration, but it would also mean that you would not be able to enforce specific policies for guest access.

Ultimately, the best place to configure the public FQDN for guest users depends on your specific needs and requirements.