How do I automate RADIUS and PPSK registration and permissions for various devices and users?

  • 4
  • Question
  • Updated 3 years ago
  • Answered
I have these SSIDs:

LEGACY - Full network access single SSID, single PSK at all sites - (Would like to decommission)
SITE - Different SSID for each site, full network access, PPSK registered users on personal devices
REGISTRATION - Open, Capture for Guest PPSK
GUEST - Internet access, firewalled from internal network auto-PPSK
8021X - Full Internal network 8021X

I would like to make it so that 8021X only grants full network access for domain users on domain devices. Currently it allows domain users with domain or personal devices full access. I would like it to give domain users on personal devices Internet access but not local network access or keep personal devices off the 8021X all together. I'm not sure how to do either option without disrupting domain users on domain devices. Any suggestions for how to set this up would be greatly appreciated.

Another hope I have is that we can automate the process for personal device registration on the SITE SSID. It would only be for domain users. Authentication could be handled through RADIUS or a PPSK issued from a domain authentication. The process would need to include a check that the devices are free from malware and viruses.

It's great to have a place for us to share questions and ideas. I have a feeling my projects will require configuring more than just the Aerohive devices. My Aerohive devices are RADIUS clients of Windows 2008 R2 Standard Servers. We also have Sophos Endpoint which might be able to help somehow. I'm hoping someone has experience integrating these technologies and can provide guidance. Thank you!
Photo of Joshua Mulloy

Joshua Mulloy

  • 4 Posts
  • 0 Reply Likes

Posted 5 years ago

  • 4
Photo of Mathew Edwards

Mathew Edwards, Employee

  • 15 Posts
  • 16 Reply Likes
Hi Joshua,

In order to only allow domain machines full access whilst restricting domain users, the simplest method (assuming you're using EAP-PEAP) would be to change your NPS policy to auth a domain computer group, rather than a domain user group. This way only domain PC's will authenticate, anyone using a personal device will not be able to access your 8021x SSID.

Step 2, allow anyone with a domain username/pw to access the 8021x SSID with restricted access. To do this you will need to have a separate NPS policy which contains 'domain users'. So now you have one policy matching domain machines and another for domain users. Then you would need to create return attributes for both these policies, lets say 1 for computers, 2 for users. On the SSID settings you will need to create 2 user profiles for the SSID, one for computers and one for users, when creating them ensure to match the attributes defined in the NPS policies. Create a third profile that is a 'dead end' e.g fake VLAN so that it has no access to the network, use this as your default profile, then set the two user/machine profiles as 'authenticated' user profiles.

So now if I connect as a domain machine, I will match one NPS policy which returns and attribute matching the 'machine' user profile on the SSID, and so places me in the unrestricted access profile. If I then connect with a personal device, I can use my user AD credentials but this time I will match the second NPS policy and be placed into the more restricted 'domain user/BYOD' profile that may contain a different VLAN, firewall policy, bandwidth limitations etc...

Hope this helps,

Mat
Photo of Abby S

Abby S, Employee

  • 94 Posts
  • 47 Reply Likes
We also have the ability to create rules based on identity and device type, so you can assign profiles that have more restricted access based on the identity of the user and the device type - such as, Joshua from a Windows computer in the domain gets full access, but Joshua from an iPhone only gets internet access. This is configured within the User Profile - Client Classification Policy. The way Mathew described above is the blanket way to do it based on identity and domain membership, while this second way allows you to configure per-device permissions. You could even do them both together - in that second user profile you create for users who are members of the domain but their machines are not, you can create rules that restrict certain types of internet access - maybe you only allow certain types of web traffic (for instance, you could make a rule blocking access to the Facebook domain for iPhones).
Photo of Joshua Mulloy

Joshua Mulloy

  • 4 Posts
  • 0 Reply Likes
Thank you both for the very helpful responses.

I think I understand Mathew. NPS responds with the first matched policy. So, the first matched policy will send a return attribute that I can use in Aerohive to configure firewall settings in each profile related to the return attribute. The third profile prevents access if the first two were not meet.

Do I need to set domain computers to use machine authentication only or can I leave them as machine/user? From what you are describing it sounds like I should make them machine only, because once the user logs in they will have the secondary restricted attribute returned even though they are on the domain device. Or does the first NPS policy recognize that they are on a domain computer and still send the full access attribute? Will the Aerohive client monitor display the machine or user that is logged in?

Abby, can the rule based identity differentiate Joshua on a domain Windows laptop vs Joshua on a personal Windows laptop? How granular can you get with per-device permissions? We would like to give certain personal devices full access but the process I have setup now is kind of clunky, PPSK manual registration and AP updating for each user that wants to print with a personal device. Also, they could take that PPSK and use it on other devices. I know you can restrict the number of devices per PPSK, but I don't want to give out a PPSK for each device they might want to register.

If they can use 8021X in a default restricted profile, but then I could add MAC ADDRESSES for trusted personal devices that get extra benefits, that could be very helpful. That would take care of:

Domain Users on Domain Devices
Domain Users with Personal Devices
Domain Users with Privileged Personal Devices

I could probably get my SSIDs down to 8021X, GUEST, and REGISTRATION. That would be ideal!
Photo of Joshua Mulloy

Joshua Mulloy

  • 4 Posts
  • 0 Reply Likes
Admin on Any Device

Could I setup an admin user NPS policy tied to one user account? So a designated admin account could gain full network access whether on a domain asset or unregistered asset? I am thinking for initial configuration or if the client lost trust. So four profiles and I would place the admin NPS policy first?
Photo of Abby S

Abby S, Employee

  • 94 Posts
  • 47 Reply Likes
Domain user on Corp Windows laptop vs Domain user on personal Windows laptop - the NPS policy that checks machine account is easiest, but for Windows devices, we can also examine whether they are part of the domain (if you check the config section for the classification policy, one of the toggles is whether they are a member of a known domain, and you can configure the name of your domain). This works well for Windows computer, which always transmit the domain in some form. It is less effective on non-Windows devices, but still possible if you make sure to configure the domain information exactly how it is transmitted for each type of device (mostly mac and linux).

And yes, you could easily set up another OU group (say Device Admins or something), and tie another NPS rule to that particular group. You'll have to set up the returned attributes to return Tunnel Type, Tunnel Medium Type, and Tunnel Private Group ID (same as you'd do above), and use a different attribute and User Profile ID to have the different privileges :-)
Photo of Patrick Bouchard

Patrick Bouchard

  • 2 Posts
  • 0 Reply Likes
Hi Abby and Mathiew, I want to make the network...like all computers that are in my Ad must be automaticly accepted on the Wifi but, if a username/password is accepted but the machine isn't in the domain, the pc will be redirected in a public vlan...do you have a faq or video explain how to do it ? thanks !
Photo of Jade Rampulla

Jade Rampulla

  • 36 Posts
  • 1 Reply Like
A few things...

It's best to do machine authentication for the clients via GPO. There's a decent tutorial here (Change to machine auth in figure 5):

http://technet.microsoft.com/en-us/ma...

Vista and later require 1 GPO policy and XP machines require a 2nd GPO policy if you have a mixed environment of domain machines.

Client classification rules DO NOT determine domain membership. Aerohive documentation states this:

"Known: When a rule specifies Known as the device domain, devices apply the rule if they detect a domain name during the 802.1X/EAP login process. The exact domain name is irrelevant.

Unknown: When a rule specifies Unknown as the device domain, devices apply the rule if they do not detect any domain name, perhaps because a user authentication method other than 802.1X/EAP is used that does not require users to submit a domain name when logging in."

In a nutshell, the submitted username is the only thing evaluated for "Known" or "Unknown" domain membership. You might get unintended results if you use that...we did. We took non-domain machines, changed the login string format, and got assigned a different user profile than we wanted.

If you want actual domain machine membership considered instead of just the username submitted, NPS must be configured to check a specific AD universal security group that contains domain machines. That's what Matthew was getting at.

As a side note, if you're using an Aerohive AP as a RADIUS server (Which we are because we have several small offices and would rather not setup 20 Windows RADIUS servers or have RADIUS traffic dependent on a WAN connection), the Aerohive AP RADIUS service has the ability to check an AD universal security group for membership and return a RADIUS attribute to match to a user profile...very cool!!! For our configuration, anything that doesn't match the RADIUS attribute we expect for domain machines, gets assigned a default BYOD user profile. I'm assuming this is what most people are looking for.

Another side note...if you make changes to Aerohive and/or NPS RADIUS while converting an existing mixed auth (machine and user) SSID to only machine based auth, your clients could fall off the network if they decide to use user auth instead of machine auth. You'll be forced to undo your changes or make them plug into wired to get your new GPO settings (Forcing machine auth). All your domain machines need to know about the new SSID settings through GPO before you make Aerohive and/or RADIUS changes!!!

It's probably better to create a new SSID on the AP's, test it with your different device types (XP, Vista, Win 7, Win 8), push the new GPO (With only machine based authentication) to all your devices, verify the policy acceptance on devices, and remove the old GPO that allowed mixed auth.

Patrick, machine authentication with GPO policies (As explained in my post and the previous ones) will allow your domain computers to connect automatically and enable non-domain devices to get a different RADIUS attribute than the domain ones which match to a different user profile with a different VLAN.

I'm not aware of a video or any complete set of documentation detailing how to do this step by step. Each environment is different depending on the type of RADIUS server, Windows infrastructure, certificate infrastructure, and clients. There isn't really a cookie-cutter example. I'd suggest contacting an Aerohive sales engineer, vendor partner, or support for help.
Photo of Crowdie

Crowdie, Champ

  • 972 Posts
  • 272 Reply Likes
My question is how do you create the following rule sets:

1. Machine + User Authentication = domain access
2. Machine Authentication only = waiting for User Authentication
3. User Authentication only = no access

I have not been able to find any way with Aerohive to check during user authentication assessment if a wireless client is machine authenticated.
Photo of Jade Rampulla

Jade Rampulla

  • 36 Posts
  • 1 Reply Like
When the client Wifi profile settings specify machine + user authentication (Default in Windows without GPO), the client device could send either and you don't really have control over it.

Instead we use GPO to force the client Wifi profile settings to use machine authentication. To enforce machine authentication on the Aerohive side, don't allow user authentication in your RADIUS policies. Make sure your RADIUS policies do a lookup to an AD group that only has machine accounts...NOT users.

If a device tries to do user authentication, it will fail because the RADIUS policy looks in the AD group and doesn't find the user.

Does this help?
Photo of Crowdie

Crowdie, Champ

  • 972 Posts
  • 272 Reply Likes
The issue is me is more how do I implement rule 1 (Machine+User auth) and rule 3 (user auth only = no access) in a single network policy. I outlined the issue at http://community.aerohive.com/aerohiv... but it currently appears that you cannot.

I see this issue and the difficulty getting firewall logs in real-time (http://community.aerohive.com/aerohiv...) as the two biggest issues with the Aerohive wireless solution at this point in time.
Photo of Jade Rampulla

Jade Rampulla

  • 36 Posts
  • 1 Reply Like
I read through both your issues and I completely agree...definitely valid. My biggest Aerohive issue is the lack of filtering options on the event logs in the monitor tab. If you get into the internal DB, there's 1000x more info. Make it available in the GUI Aerohive!!!...another issue for another post :)

I've never seen what you described in your first post... in reference to a laptop booting up and doing machine authentication (Matching to 1 Aerohive user profile), then a user logging in and the authentication changes to user auth (Matching to a different Aerohive user profile). I've always seen 1 or the other throughout boot-up, login and continued usage but all the stuff I'm working with usually has a GPO forcing a single type of auth. I wonder if forcing a single type of authentication through GPO could solve your problem, which leads to my next thought...

In response to your first issue, I'm curious if a possible solution is to use machine authentication only (And get rid of user authentication) through GPO settings but with a few back end changes. You might be able to organize your AD security groups so specific machine accounts in AD that need restrictions are in a different AD security group than the rest of your machine accounts (Located in a separate AD security group). This would allow your RADIUS server (Aerohive AP's, NPS, or something else) to differentiate between different types of machine accounts and return a different RADIUS attribute which matches to a different Aerohive user profile.

Obviously if you have different types of users logging into the same machines that need different Aerohive user profiles assigned, my idea isn't that useful. I could definitely see this as a big issue for schools that have library laptops requiring different users to have different levels of access (Through assigned Aerohive user profiles) on the same machine. Is that your type of scenario?
Photo of Crowdie

Crowdie, Champ

  • 972 Posts
  • 272 Reply Likes
I am seeing it a lot in medical facilities that use pool wireless devices. When the staff member arrives they take one of the wireless devices that is fully charged and start their ten hour shift.

If we go with a computer only authentication process then the wireless network is only aware of the wireless device so we can't apply an appropriate user profile for the staff member.

If we go with a computer and user authentication process we can't stop Windows based BYOD devices being able to get domain access by the staff member entering their username in the format domain\username.

As other wireless vendors support only allowing access after both machine and user authentication has been completed I am obviously not the only person who needs this functionality.
Photo of Jade Rampulla

Jade Rampulla

  • 36 Posts
  • 1 Reply Like
That's an interesting scenario. It makes sense what you're trying to do. Wish I knew how to make it happen. I can see this being an issue down the road for more than just medical and school environments as IT people become more security focused.

I forwarded this post to a very smart Aerohive guy I've worked with on Aerohive RADIUS design. If there's any solution I'm hoping he can come back with something.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Crowdie,

How exactly are other vendors solving this in a secure way? The issue is with the typical EAP types not supporting chaining (EAP-PEAP, EAP-TTLS and EAP-TLS), something which EAP-TEAP is meant to ultimately resolve.

Nick
Photo of Crowdie

Crowdie, Champ

  • 972 Posts
  • 272 Reply Likes
From my original post at http://community.aerohive.com/aerohiv...:

Possible Resolution #2
Another option is to implement a machine authentication MAC address table and when a wireless client completes machine authentication the MAC address of the wireless client is placed into the machine authentication MAC address table. When a wireless client successfully completes user authentication the wireless client's MAC address is looked up in the machine authentication MAC address table and, if it is located, the machine+user authentication process is completed.

This method is currently utilised by Aruba. The machine authentication MAC address table is stored on the Aruba wireless LAN controller and you can see the machine authentication MAC address table using the CLI command show dot1x machine-auth-table.

The Cisco Access Control Server (ACS) has similar functionality where you can add a check in the user authentication rule so the rule is only matched if the wireless client is machine authenticated.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Yes, but... hmm... that is a kludge and a hack when the issue is with the EAP type alone and not the authenticator (switch or AP), which should be oblivious to the EAP and type of authentication occurring unless it itself terminates it. I have concerns about its security properties when using a MAC address alone for binding (as in there is no security). There are also portability concerns in a vendor heterogeneous environment as it is non-standard behaviour.
Photo of Crowdie

Crowdie, Champ

  • 972 Posts
  • 272 Reply Likes
The issue we are facing is now so I need something I can implement today. If I took the Aerohive access points out and replaced them with Aruba access points I would have a solution.

Besides, isn't it the early hours of the morning in the UK?
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
It depends how you define solution, I guess. Having something that appeared to work yet was fundamentally broken from a security perspective because it is vulnerable to MAC address spoofing when the second authentication occurs would not meet my definition. It could also be achieved by a bad acting third party as there is a race condition.

I'll probably go to bed around 2! :P
Photo of Crowdie

Crowdie, Champ

  • 972 Posts
  • 272 Reply Likes
I am open to ideas on how to resolve this in a relatively quick manner.

Since it is 13:37 here that only gives you 23 minutes to come up with a resolution :-)
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
The Aruba solution is likely to be completely and trivially broken as you can probably:

1) Perform the first device/machine phase of the authentication on the approved device and silence it.

2) Before any time out occurs, perform the second user phase on another device that spoofs the MAC address of the first.

If you need a quick, insecure workaround, why not just perform user authentication only and use the MAC address of the client to decide if you're going to allow it on or not?

For a secure solution today, have you considered using Cisco's AnyConnect supplicant with ISE as the RADIUS backend that can perform chaining by using an EAP type they implement/control?

http://www.cisco.com/en/US/solutions/collateral/ns340/ns414/ns742/ns744/docs/howto_80_eapchaining_deployment.pdf

A potential caveat here is that there is presently a bug in HiveOS's accounting whereby an Acct-Session-Id is not sent in the Accounting-On and Accounting-Off forms of Accounting-Request packets. Cisco's ISE will probably expect by-the-book behaviour and error to some degree.

See the following for reference:
http://community.aerohive.com/aerohive/topics/radius_accounting_issue_with_330_and_320_series_aps

Nick
Photo of Joshua Mulloy

Joshua Mulloy

  • 4 Posts
  • 0 Reply Likes
I tried the MAC filtering on Aerohive, even though it's trivially defeated, it did exactly what I wanted, even with both computer and user authentication active in RADIUS. The problem I ran into is that you are limited to (I think it was) 128 MAC addresses.

Using just machine authentication will take care of making sure only Domain assets can access the 802.1X. Unfortunately, you will not know who is using which asset which is exactly the problem I have in our highly shared environment. I need to know who is on which machine to apply user group profiles.

I haven't been able to figure out a way to identify a user on 802.1X and keep BYOD off of it.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Use your own RADIUS server, like NPS to get around that limit? There isn't a standards based, widely applicable secure solution to this today.
Photo of Sarah Banks

Sarah Banks

  • 75 Posts
  • 4 Reply Likes
Folks, thanks for your interest and feedback. I understand the pain point - Crowdie, you did a great job of delineating an example, and I share some of the concerns Nick presents as well. I'll take this back and discuss it internally - we've got it.

(I know, I get no extra kudos, it's not 2am in the UK :) But I am listening! :))
Photo of Patrick Bouchard

Patrick Bouchard

  • 2 Posts
  • 0 Reply Likes
Hi, I want to make a installation in our school like this post..We have NPS Server from Microsoft with 128 AP121, we want to permit access from authentication by the NPS(2008 entreprise) on our 2003 AD(2003 R2 std). our goal is permit access on our local vlan to the computer in the AD and user authenticated, but if a user is authenticated in the AD and his computer is not a computer of the domain, the AP will give to the computer a public vlan to communicate with internet only. IS it possible ? if yes, Can I do this without certificate ?
Photo of Jade Rampulla

Jade Rampulla

  • 36 Posts
  • 1 Reply Like
If you're goal is to allow your domain machines to match to a specific Aerohive user profile (VLAN and AP firewall policy), with the rest of your devices (Considered some form of BYOD) doing user authentication that matches to a separate Aerohive user profile (VLAN and AP firewall policy)....YES this is possible.

As Nick and Crowdie mentioned, if an individual domain machine or multiple domain machines have different users that login throughout the day and certain users need different Aeroihve user profiles assigned...that's NOT possible at this point. The functionality will come in the future with the EAP-TEAP protocol as Nick mentioned.
Photo of Jade Rampulla

Jade Rampulla

  • 36 Posts
  • 1 Reply Like
Forgot to add this...

You can arrange different types of domain machines to different AD groups and have your RADIUS server (Aerohive AP, NPS, or other) return different attributes to match to different Aerohive user profiles.

For example, a school could have domain machines for teachers organized in 1 AD group, administrative staff domain machines in a 2nd AD group, and student domain machines in a 3rd AD group. RADIUS can return different attributes for each AD group that will match to different Aerohive user profiles.

On top of this, the rest of your devices that aren't part of the domain can do RADIUS user authentication. I'd recommend not returning RADIUS attributes for user authentication unless you need to apply different user profiles for different users. In Aerohive, set your default user profile (That doesn't get RADIUS attributes returned) to handle your user authentication for BYOD type devices. The rest of your user profiles attributes must match up to the different RADIUS attributes returned for the different types of machines I previously mentioned.

The great thing is you can have all of this operating on a single SSID which reduces radio time for beacons (Since you don't have multiple SSID's handling multiple functions), and lessens user confusion. Tell your users that they can connect everything to a single SSID and you'll handle all the back end...they'll appreciate it!
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
The standards based way of initially matching a user profile is to use the Filter-Id AVP. The Tunnel-Private-Group-Id AVP should only be used to specify the VLAN.
Photo of Jade Rampulla

Jade Rampulla

  • 36 Posts
  • 1 Reply Like
To answer your other question about certificates...

If you don't use certificates and the clients don't validate certificate authenticity, an attacker can impersonate your AP and capture credentials. When you use certificates and an attacker impersonates your AP, the client won't be able to validate the certificate and won't send the credentials...that's what you want!

NPS will need a certificate and you'll need a CA. Make sure your clients and NPS are all part of the same trusted certificate infrastructure so you can enable the check box in the Wifi client profile "Validate Server Certificate". You can un-check the box on the client side during testing if you want to verify RADIUS functionality without the certificate infrastructure setup. Don't leave this as your permanent setup because you'll be vulnerable to attacks as mentioned before. I also recommend pushing a GPO policy for the client side Wifi profile settings. See here:

http://technet.microsoft.com/en-us/ma...

If you use Aerohive AP's as your RADIUS server instead of Aerohive, things are much simper. You can export the "Default_CA.pem" certificate from HiveManager, import to your domain controller, push to your clients as a trusted certificate authority through GPO and you're all set. You don't need a CA at all.

Hope this helps!
Photo of Smitty

Smitty

  • 37 Posts
  • 3 Reply Likes
Jade,

You mentioned...

"As a side note, if you're using an Aerohive AP as a RADIUS server (Which we are because we have several small offices and would rather not setup 20 Windows RADIUS servers or have RADIUS traffic dependent on a WAN connection), the Aerohive AP RADIUS service has the ability to check an AD universal security group for membership and return a RADIUS attribute to match to a user profile...very cool!!! For our configuration, anything that doesn't match the RADIUS attribute we expect for domain machines, gets assigned a default BYOD user profile. I'm assuming this is what most people are looking for. "

That is pretty much exactly what I am trying to do. I would like tracking by the user name instead of Host\Machine Name...but I can settle with that for now. However...I have not been able to get that to work at all. It shows I am authenticated with machine authentication...but for some reason I am still being assigned the wrong user profile. Can you by chance elaborate a bit on how you got that to work? I set my AAA setting to match Domain Computers and reassign to a user profile with no restrictions. Then the SSID has a default user profile with BYOD restrictions. However...everything is getting BYOD restrictions at this point. I did set my machine to 'Machine Auth' only.

Thank you.
Photo of Jade Rampulla

Jade Rampulla

  • 36 Posts
  • 1 Reply Like
Are you using Aerohive for RADIUS services or an external RADIUS server like Windows, Cisco, etc? It sounds like your RADIUS server isn't returning the correct RADIUS attributes to match up with the user profile. Or it's the other way around and your RADIUS server is returning attributes but you need to configure your user profile to use the attributes returned by the RADIUS server. You can always use the client monitoring tool to see what attributes come back from the RADIUS server. Then double check your user profile to see if it matches up.
Photo of Smitty

Smitty

  • 37 Posts
  • 3 Reply Likes
I am using the Aerohive RADIUS. I have figured out a work around. My AD servers are not returning RADIUS attributes when I select either 'Domain Computers' or 'Domain Users'. I created a new group called 'Wireless Computers' and that returns just fine...along with every other group I have. Just 'Domain Computers' and 'Domain Users' do not return for some reason. The only problem is I have to remember to put all the new computer accounts in this new group.

Thanks.
Photo of Jade Rampulla

Jade Rampulla

  • 36 Posts
  • 1 Reply Like
Yea that seems to be a necessary evil. We have to do the same thing. I'm not an AD expert, but I don't think the pre-built "Domain Computers" and "Domain Users" containers aren't universal security groups. I think that's why RADIUS isn't able to verify machine membership in the group...and why RADIUS wasn't returning attributes. The group has to be a manually created universal security group with all your machine accounts inside it. Then the RADIUS server can lookup machine membership and return attributes.
Photo of Kevin Whelan

Kevin Whelan

  • 53 Posts
  • 2 Reply Likes
I have Question related to this,
Currently using one SSID with AD  802.1x certs for domain joined machines and group polices so all automatic  VLAN 1

2nd SSID for teachers BYOD with PPSK VLAN2


Because of the constant tiresome manual work involving maintaining a separate database of ppsk users I would like to ditch PPSK and make the teachers BYOD devices use radius but they would need to be username/password due to the complications of certificates on various mobile platforms

Could I use the first 802.1x SSID and have rules/attributes that domain joined machines used certs and got VLAN1, BYOD devices used radius username/password and got VLAN 2. (and couldn't use those credentials to access VLAN1)

Would I have to add a separate 802.1x SSID to achieve this 
Would radius just skip/pass rules until anyone with ad username /password could then potentially connect back to VLAN1 bypassing the cert requirement
Perhaps this would require 2 radius servers