PEAP validation against a different, secondary domain?

Question

Probably a little bit confusing, so let me explain the situation.

Our company wants to implement a corporate wireless LAN with PEAP authentication. Unfortunately, someone made a big mistake in our Active Directory design 10 years ago.

The domain name we are using, company.ch, is not owned by our company, but by someone else. This makes it impossible to issue a public SSL certificate for the RADIUS server, and our Active Directory domain is too big to rename.

We already thought about using our private PKI and rolling out the CA-generated certificate via GPO but that would only cover our corporate-managed clients, and not any of the devices in our environment from our BYOD policy (Smartphones, Tablets, Laptops..)

Is there a way to add a secondary domain name like company2.ch, issue a public certificate against it and join RADIUS to that secondary domain as well, so we can configure that secondary domain via DHCP for all the client pools?

Or is there another way with, for example, a new RADIUS server on its own domain (company2.ch) which is connected with some kind of trust to the company.ch domain?

I'm not a client-server guy, but hopefully you get my drift.

Answer 1

First of all, let me say that you (well, your bosses, maybe) really need to get off of using a domain you don't own. You say it's too big to do that now, but you're being short-sighted. If it's "too big" to change now, what happens in the future, when it's even bigger? You're just letting the problem grow and grow, until (if the company actually does succeed and continue to grow) you'll end up with a problem which really will be "too big" to handle, and you'll spend fantastic amounts of money and time and create a lot of user-impact to correct what you probably could correct now for much less effort. At the very least, you should see if you can buy the domain your AD is using from its current owner, which would be the quickest way to correct this.

Anyway, having said, and assuming your bosses aren't willing to actually be reasonable, smart, or think further into the future than their next bonus check, there actually is a pretty east way around this, which you mentioned in your question.

What you would want to do is:

1. Create a second child domain in your Active Directory forest.
   • Pick a domain you own this time, or buy whatever domain you pick, for the love of God.
2. Create a trust between the new domain and the old one (within AD).
3. Create appropriate user groups, resources and permissions in new domain.
   • Setup a RADIUS/NPS server here that's got permissions to authenticate against the old domain, or perhaps just your RADIUS-capable devices, and allow them to authenticate against the old domain (or however you want to do it).
4. Manage permissions in old domain so that users of new domain have required access.
   • For example, make sure that any SSL cert you purchase for this domain will be accepted by the old domain, if that's the route you go.
5. (OPTIONAL, but HIGHLY RECOMMENDED) Use the new child domain to migrate away from the old one you don't actually own
   • Once the trusts are established and working, you can use them to migrate users off of the old domain you don't own, onto something you do, and make the problem go away eventually.
     • I am actually in the middle of a Windows Active Directory domain migration, and this is how we're handling it too.
     • We've created a second child domain, established trusts, and slowly started migrating users, services, machines (everything) over to the new domain, so the old, broken domain will eventually be empty and unused, at which point we'll dispose of it.