Multiple Active Directory Authentication in different forests.

  • 2
  • Question
  • Updated 3 years ago
  • Answered
We currently have created two SSID, one for students and one for staff. I would like to combine them into one SSID but I can not because our staff and students are in different domains, in different forests. I am told we can not authenticate to two separate domains in different forests in the same SSID.

Is this the case or has this changed?

Thanks in advance,

Harry
Photo of Harry Zahlis

Harry Zahlis

  • 22 Posts
  • 3 Reply Likes

Posted 5 years ago

  • 2
Photo of Mike Kouri

Mike Kouri, Official Rep

  • 1030 Posts
  • 271 Reply Likes
Harry,
I'm sorry, but I don't see any way to accomplish what you want with our current feature set. I hope I am wrong and someone else here can jump in with a creative solution, but nothing leaps to my mind this morning.
Photo of Harry Zahlis

Harry Zahlis

  • 22 Posts
  • 3 Reply Likes
Hi Mike -

Thanks for the quick response.

If this doesn't exist I would like to request it. The previous vender I was using allowed me to do this and when we moved to Aerohive we asked if multiple domains was an issue and we were assured it was not. I guess we weren't specific about the forest issue.

I really don't want to have to create another domain just for student authentication for wireless. I'm not sure why the forest should make a difference when authenticating users if accounts are created in the domain that allow for user look-ups.

If we can solve this issue my wireless world would be perfect! ;-)

Thanks,

Harry
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
This is easily achievable if you use an external RADIUS server with WPA2-Enterprise/802.1X. Why not use NPS if you're a Microsoft shop?

Or are you using one of those 'evil' captive portal things? :P
Photo of Harry Zahlis

Harry Zahlis

  • 22 Posts
  • 3 Reply Likes
Hi Nick -

I have Active Directory, why would I want to set up a secondary environment for authentication? Certainly if I have to look at other alternatives I will but I would rather use what I have.

No evil portal thing...yet. ;-)

Harry
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
I didn't say that, you can use FreeRADIUS against Active Directory! So, NPS is your answer?
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Why exactly have you put your staff and students in different forests by the way! Seems nuts to me! :P
Photo of Harry Zahlis

Harry Zahlis

  • 22 Posts
  • 3 Reply Likes
Hi Nick -

Misunderstood what you meant.

I guess I want what I had before :-)

Our previous vender just required an account to do the look-up in the domains we wanted to query against. I'm not sure why the forest issue should even matter. If the credentials can be passed and authenticated that should be all that matters.

Harry
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
It is different because you have to query at a global catalog to query cross forest, and it's less efficient, and the LDAP query has to be structured so it will work.

Running your own RADIUS server is really easy and quick to set up with NPS. It's how I would do what you're after.
Photo of Harry Zahlis

Harry Zahlis

  • 22 Posts
  • 3 Reply Likes
Nick -

Security. We wanted them separate. Another big reason is we are a community college with a huge student population - we have over 200K student accounts in our student domain.

Harry
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
If you're running at that scale, I would run your own RADIUS infrastructure for definite!
Photo of Harry Zahlis

Harry Zahlis

  • 22 Posts
  • 3 Reply Likes
Hi Nick -

And we may get there. I can certainly see benefits for RADIUS, especially when we finally get to implementing a "portal thing" :-) I can also see some benefit to creating a child domain for our students for other authentication purposes which would solve this issue. Unfortunately I have to take into account levels 8, 9 and 10 of the OSI model (politics, religion and budget) to make changes to our multi-college Active Directory domain.

Regardless, our old vender (8 years old) figured out how to accomplish this, I was just a little surprised why it wouldn't work in Aerohive (this may be an issue of other venders as well).

Harry
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
There are many good reasons why you shouldn't query a GC by default so the implementation doesn't surprise me, and it's likely a good thing on balance therefore.

Aerohive could certainly add it in as an option though for those that want it, like yourselves. I suspect you will be the first to have asked / hit the issue...
Photo of Sarah Banks

Sarah Banks

  • 75 Posts
  • 4 Reply Likes
Hi Harry, as Mike correctly pointed out, this isn't something that we support today. As Nick correctly points out, you're (unfortunately) the first person I've had request such a feature. That's not to say it can't be done, however. I particularly appreciate your comments about levels 8, 9 and 10 of the OSI model; I understand technical changes aren't always made for technical reasons. I can't commit to this, but I'll certainly take it into consideration.
Photo of Roberto Casula

Roberto Casula, Champ

  • 231 Posts
  • 111 Reply Likes
I just wanted to chime in here. Aerohive DOES support multiple domains and multiple forests for AD authentication from an AP/HiveOS VA acting as RADIUS server. The requirement though is for there to be a trust-relationship in place between the forests.

This is because the AD authentication with Aerohive works by the AP joining a domain as a workstation. The authentication process works exactly the same as it would for a user logging on to a normal Windows workstation. The workstation authenticates the user against a domain controller in the domain for which it is a member and for security principals in another forest, the inter-forest trust is used by that DC to delegate a credential validation to a DC in the other forest.

If you do not care about doing LDAP lookups to map AD group membership (or some other LDAP attribute) to different user profiles, and if you disable the LDAP user validation mechanism (in the AAA Server settings under "Query database to check if user exists"), you don't actually need to do anything else...it just works.

However most people would want to perform at least the LDAP group mappings to restrict who can authenticate and/or assign different groups of users to different user profiles.

For the LDAP lookup to work, you need to tell the AP about a domain controller in the other forest. This is done in the AAA Directory Settings right down the bottom under "Optional Settings -> Multiple Domain Authentication". Once you've filled these details in (the account only needs to have read access to the directory, doesn't need to be an administrator account), you will be able to select the other domain in the AAA Server Settings where you perform the group mappings and browse the directory tree from there just like you can with the "primary" domain.

For domains in the SAME forest, you can either do the same thing, or you can check the "Global Catalog" checkbox in the AAA Server settings which will make the system query the GC rather than the standard LDAP database.

Unfortunately, Aerohive's documentation here is a little confusing (as is the way the UI has been implemented, especially when you want a resilient configuration with multiple APs acting as RADIUS and multiple domain controllers), but it does all work very well.

One other little issue which I've just found from some testing this evening (which may be a bug) is that the EAP identity has to be supplied in NetBIOS-Domain\username or FQDN\username format (e.g. ACME\jsmith or acme.com\jsmith) and not UPN/realm format (i.e. jsmith@acme.com). A debug of the authentication (using _debug radiusd on the AP CLI) shows it is resolving the name correctly in both instances, but the NTLM challenge/response fails in the UPN/realm case for some reason. This is true whether a single domain is configured or multiple domains.

It should also be possible to support multiple forests WITHOUT there being a trust relationship and without using an external RADIUS server, however I've not set this up (and it's pretty clunky). You should be able to combine the AP RADIUS Proxy function with the AP RADIUS server function. The authentication then goes like this:

The AP the user is connecting to sends the EAP identity to an AP configured as a RADIUS Proxy. The proxy configuration looks at this identity and matches the domain part, resulting in it proxying the authentication to ANOTHER AP which is acting as the RADIUS server for that domain. You would need to have one (preferably two) APs per domain still plus another one (preferably two) APs as RADIUS proxies, but you can have a single SSID using the proxy rather than two SSIDs.

This is exactly what you would do in this situation if you were using external Microsoft IAS/NPS servers. You'd configure one to front-up as a proxy to the external domain as IAS/NPS servers (just like the Aerohive system) can only authenticate users directly against their own or trusted domains - to authenticate against an untrusted foreign forest, you would set up a connection request policy (i.e. a proxy policy) to forward requests to an IAS/NPS server in the other forest.

In fact, this is exactly how the "Eduroam" mechanism works in the UK over JANET (Eduroam allows any user from any participating college/university to go to any other participating college/university and log on to their wireless network using their home domain credentials - the local wireless sends requests to a local RADIUS server which proxies requests for non-local domains to the JANET Eduroam "cloud" RADIUS proxy which further proxies the request on to the RADIUS server at the user's "home" college/university. Each university only needs to know about its local domain(s) and the JANET forwarding proxy. It works very nicely!).

I can't see any obvious reason why this shouldn't work entirely inside the Aerohive configuration...but as I say, I haven't tried it (yet!)
Photo of David Jackson

David Jackson

  • 1 Post
  • 0 Reply Likes
Hi Roberto,

It has been a while since this post.  Has there been any update regarding the documentation of setting up an Aerohive AP as a Radius server with resiliency?

Unfortunately, Aerohive's documentation here is a little confusing (as is the way the UI has been implemented, especially when you want a resilient configuration with multiple APs acting as RADIUS and multiple domain controllers), but it does all work very well.
Photo of Roberto Casula

Roberto Casula, Champ

  • 231 Posts
  • 111 Reply Likes
The documentation hasn't really been updated, but the way it is set up in the GUI has been changed since this post and it is a little more logical now. As was always the case (once you get your head around what the GUI is actually doing), it's fairly straightforward to set up if you only have a single AD domain.

You need a AAA User Directory Settings object for each Domain Controller that you want to use. It doesn't matter which of your APs you use as the "Aerohive device for Active Directory Connection Setup" in the User Directory Settings objects.

You then need a single AAA Server Settings object which references each of your User Directory Settings objects as the Primary/Backup directories (you can have up to four in total). Do not set up any shared secrets in the RADIUS Clients/NAS Settings section. You will need to set up your authentication parameters. There are lots of options here depending on what you want to do. For optimum security, specify only to use EAP-TLS, obtain the RADIUS server certificates from your Enterprise CA, set up your AD CA infrastructure with auto-enrolment and push out configuration to clients using Group Policy. There are plenty of guides on generically setting this up (none of this is Aerohive-specific) on Microsoft's technet site.

Then you assign the AAA Server object to whichever APs you want to be your RADIUS servers (these APs must have static IP addresses).

Next, you need to create a AAA Client Settings object that lists the APs you have set to be RADIUS servers (again, you can assign up to to four). Leave the shared secret blank and it will be automatically generated within the hive.

Finally, use the AAA Client Settings object in your authentication for your SSID.

However, unless you have a relatively small environment, I would suggest using external RADIUS servers (Microsoft NPS, FreeRADIUS etc.) or at the very least dedicating some APs or CVGs to being RADIUS servers only.
Photo of Roberto Casula

Roberto Casula, Champ

  • 231 Posts
  • 111 Reply Likes
Also, I believe the above is only true if using PEAP-EAP-MSCHAPV2. If using EAP-TLS, cross-forest authentication won't work because Microsoft don't support Kerberos certificate-based authentication across forests even when there is a forest trust (this is due to the way the Service Principal Name is looked up - it relies on the Global Catalog which will not contain the necessary data for users in the other forest).

For EAP-TLS, I believe the RADIUS Proxy mechanism would work - I will find out very soon, as we need to set this up for a customer, so I will be labbing this very shortly.
Photo of Roberto Casula

Roberto Casula, Champ

  • 231 Posts
  • 111 Reply Likes
I can confirm that the RADIUS Proxy configuration works fine with EAP-TLS authentication against two different Active Directory forests.

As a minimum (i.e. no resiliency), you need to configure:

1 AP (e.g. AP_01) to authenticate via Active Directory to forest A (e.g. acme.com)
1 AP (e.g. AP_02) to authenticate via Active Directory to forest B (e.g. contoso.com)

AAA RADIUS Server, AAA RADIUS Client settings and AAA Directory settings must be configured as appropriate.

1 AP (e.g. AP_03) to act as a RADIUS Proxy with realms set up as follows:

acme.com -> AP_01
contoso.com -> AP_02

Realm type is probably going to be NAI (i.e. user@acme.com format rather than acme.com\user) but this could depend on how you have set up your client certificates.

You must specify a shared secret in the RADIUS Proxy settings for the connection to AP_01 and AP_02. This shared secret must also be set up in the corresponding AAA Server objects with the NAS Client being AP_03.

You must then create a third AAA RADIUS Client object for AP_03 (the NAS secret should be left blank to let the Aerohive automatic secret generation do its magic).

In your SSID mapping, you then specify the AP_03 RADIUS client object as the RADIUS server.

In AP_01's services configuration, select the AAA RADIUS Server object for AP_01
In AP_02's services configuration, select the AAA RADIUS Server object for AP-02
In AP_03's services configuration, select the AAA RADIUS Proxy object and leave the AAA RADIUS Server setting blank

For resiliency, as a minimum you probably want two APs being RADIUS servers for each forest and two APs being RADIUS proxies, requiring 6 APs in total.

One word of caution: If you are using ID Manager in your policy, you may encounter an issue where the election of the ID Manager RADSEC proxy conflicts with your proxy settings, preventing them from working. This appears to be a bug in the election process (it should not elect an AP that is already configured as a RADIUS proxy to be a RADSEC proxy for ID Manager).
Photo of Roberto Casula

Roberto Casula, Champ

  • 231 Posts
  • 111 Reply Likes
In fact it might not be a "bug" but rather a limitation because of the way ID Manager integration currently works (it creates a DEFAULT proxy realm configuration on all APs). So if you have ID Manager, you will have to apply a different network policy that does not reference the SSIDs using ID Manager to the APs you want to be your RADIUS proxies.
Photo of Harry Zahlis

Harry Zahlis

  • 22 Posts
  • 3 Reply Likes
Hi Roberto -

Thank you very much for your responses. I truly appreciate the time you took to test and then comment. I will be working with our integrator to see what we can do to replicate your findings.

I really want to get to a single SSID with authentication against two domains not in the same forest. It looks like you ahve found a way.

Thanks,

Harry
Photo of Sarah Banks

Sarah Banks

  • 75 Posts
  • 4 Reply Likes
Howdy! I asked the team here to confirm that we do support multiple AD auth in different forests, and the auths do succeed, taking into account the NTLM way of usernames; that is, domain\user, versus user@domain. I apologize for the confusion. Roberto, thanks for the detailed and precise comments!
Photo of Harry Zahlis

Harry Zahlis

  • 22 Posts
  • 3 Reply Likes
HI Sarah -

Thanks for the clarification and confirmation, much appreciated.

Harry
Photo of Cameron Revard

Cameron Revard

  • 1 Post
  • 0 Reply Likes
Personally it seems crazy to me that DNS cannot be assigned by SSID, instead it's designated at the policy level. This is something I'd love to see changed.
Photo of MST

MST

  • 152 Posts
  • 3 Reply Likes
Sorry to interrupt this post. I am in very similar situation with two different AD forests. I have used one AP and 2nd interface on the AP as bridge and added second card to the other AD Forrest. I can ping 2nd AD but can't retrieve information form it. Is that because its missing the trust relation between the forests?