Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We have some voip phones that we want to integrate into our PEAP WiFi network, and I'm concerned about just creating a standard AD account and using that. If someone got hold of such long-term account credentials, they could then use them to log into hosts and access network resources

There are some policy/setting options for locking down local access, but they don't apply to network access. eg the "Log On To" option allows you to limit what machines an account can access, but a WiFi access point talking to a NPS/domain controller appears to use the host "" - ie it doesn't set that variable. That entire solution appears to only work against domain-member Windows computers - so wouldn't help if the user came in from a Unix/Mac system for instance (or PEAP of course)

This can be expanded to a more general question about how to use Active Directory for non-Windows authentication (eg LDAP). I haven't seen any real answers and so fear it may not be possible - but you've gotta ask right? :-)

share|improve this question

The way I addressed this (and I'm not saying this is "industry standard" or "best practice") was to create a single account that they could use (like a service account), put it in a group created just for this (and used in NPS for policy matching), make that group the primary, and remove them from Domain Users. That way, even if someone managed to get the password, they would only get access to anything using "Authenticated Users", which we don't use at all.

In the event we find that the account has been compromised, we would simply create a new account with a new password, change the phone startup config file, and once all the phones got the new settings, kill the old account.

As to using a non-Active Directory user database, it can be done, but you'd have to add a non-NPS RADIUS server. I tried for a long while to get a Ubuntu server with FreeRadius to do it, but it ended up taking too much time to learn how to integrate it properly, so I went back to NPS. NPS has a way to specify that for given criteria, it should pass off the request to an external RADIUS server, so it's definitely possible.

share|improve this answer
Doesn't really work in my scenario. Your comment about removing "Domain Users" is fair - but in reality I doubt you can guarantee every computer on your network is configured such that "Domain Users" is a minimum requirement (I know I certainly cannot). What I'm really after is some kind of account flag/policy that blocks CIFS access without impacting NPS authentication. I appreciate it may not be doable ;-) – jhaar Jul 30 '14 at 21:45
I'm not sure what you mean by ""Domain Users" is a minimum requirement"? If you mean logon, then a) every computer that is joined to the domain gets Domain Users added to the local Users group, b) GPO can enforce this so it can't be removed, and c) I'm not sure what that has to do with this? Can you clarify that? Then hopefully I can answer it. :-) Otherwise, to deny access you'd either a) add an explicit deny to each share you want to protect, or b) set a GPO to deny access via network. – DarkMoon Jul 30 '14 at 21:56
You said if they weren't in "Domain Users" then they wouldn't have access, I'm saying I can't control that: I just want an AD account that can only be used for RADIUS authentication - ie cannot be used for logging into PCs, accessing CIFS shares, etc. Your GPO might do the trick - "Deny access to this computer from network" could do it: obviously I'd have to apply the policy to every computer in the domain in order to block this one account. Apparently the same policy is already applied to "Guest" - I wonder if I can add a separate Guest account? (with a password) – jhaar Jul 30 '14 at 22:12
Ah, I understand now. :-) I would add a group rather than an account, and add the group to the GPO. That way, future accounts that you may want to do the same with would only have to be added to that one group, rather than having to reconfigure and redistribute a GPO each time. – DarkMoon Jul 30 '14 at 22:44

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.