Skip to main content

How are you all doing WiFI based AD authentication?



We have an 802.1X solution that was implemented before I arrived. You can connect to the SSID but you won't get an IP address until you supply an AD username and password. That makes life interesting if you have computers that can't be permanently wired to Ethernet all the time ... like laptops.



On our standard 10.8 build, I tried a modified script tied to a LaunchAgent to detect if there was no ethernet access and then mount an existing 802.1x profile on the computer. No go, wifi on, network connected, no IP as it didn't pass credentials through.



Tried config profiles using the "Use as a Login Window configuration" option. Found that this method only works for us when a user account already exists on the system. If someone logging in doesn't have an existing account, it fails.



We're pretty tied to our existing 802.1x implementation thanks to the requirements of JANET (www.ja.net if you're interested) and their "eduroam" scheme. Change at the RADIUS end of things may not be possible but despite that i'm thinking some sort of limited machine based authentication may be the way to go.



Any thoughts?

We're using login window profiles with Radius tied to AD credentials. First time users with no mobile account cached can login using this method it just takes a bit longer than a wired connection. We're moving to Identity Guard based machine certificates and tokens. We made config profiles that requested certificates(user and machine) from our CA, but the certs were exportable so it was cancelled.

That's effectively what we have except I can't get a user with no cached mobile account to be able to log in.

We're not at 802.1x for wi-fi yet so this is theoretical but if you have device certificates in place that identify the machine as an AD member, can your network admins create a policy to allow the machine to auth to the network where the domain controllers are? Seems that's the point of 802.1x especially if you have posturing in place as well. Otherwise your clients have to get wired for that initial logon.

We are also using LoginWindow profiles (from Profile Manager on 10.8) using AD credentials to auth to RADIUS. Non-cached mobile users can login at the login window and it will create the users account.



Are you making the profile in Casper? (perhaps try Profile Manager if you are)
Are there any relevant errors int he logs when it doesn't work?
Have you put in an AD username and password in the profile so it is auth'd at the LoginWindow?

Yep, done all of that. Used our test accounts as well as my own ad accounts to test out the profile. No go.



Are you suggesting the profile should be created elsewhere and then imported into the JSS? We've exclusively used the JSS 8.71 and previous to work on this.



I'm wondering if there's something odd with our network. They're not exactly complicated profiles, so i'm wondering why existing users work but users without cached credentials have such issues.

Definitely sounds odd. If you have a machine running OS X server lying around, I would suggest firing up the Profile Manager service on it, create a profile with the wifi settings and then enrol a laptop to it and see how it goes. At least then you will know if its the JSS or not. We currently use Profile Manager for our 802.1x profiles, I haven't tried them with the JSS yet.



The only time I've seen something like you are describing is when the 802.1x authentication wasn't working at the LoginWindow, then the machine couldn't contact the radius server to verify the credentials.



There were also further enterprise wifi fixes in 10.8.4, are you running with the latest combo update?

ive had problems using the profile created with profile manager or casper. instead i've created the profile using IPCU and then packaging it with composer using a postflight script to install it via profiles command. this has worked 100% of the time for me

How do you get the "Use as a Login Window configuration" option to appear in IPCU? I dont see it in there.

You must edit the file manually. You need to add a setup mode.



<key>ProxyType</key>
<string>None</string>
<key>SSID_STR</key>
<string>Your Network</string>
<key>SetupModes</key>



<array>



<string>Loginwindow</string>



</array>
</dict>
<dict>

If you want machines to get IP addresses before logging in, you need to enable computer based AD authentication with AD certificates.



Please read it here;
https://jamfnation.jamfsoftware.com/discussion.html?id=7127



We have a Configuration Profile with Network and AD Certificate payloads configured for that.
You might need to work with your network engineers to get the RADIUS setup to issue IPs for machines with AD certs if you don't have the RADIUS setup already for machine authentication.

Check your RADIUS logs to see what's going on when you try logging in wireless with a non-cached account. If nothing's logging or there's an error, then it's probably an issue with the client side (i.e. profile settings). If it is successfully authenticating but still not logging in, then it's probably a network issue (i.e. can you get to AD from your wireless vlan?)

We're beholden to various agreements such as those made with the UK's Joint Academic Network (or JANET if you prefer). The timescale on this just shot up from weeks to months.



Thanks all. This has somewhat vindicated our original policy of wired only.

Terms & ConditionsCookie settings