Security

Hey All,

 

I am running into some limitations with my .1x implementation and looking for a different build out.  My idea is to combine captive portal and mac address authentication.  Is there a way to have the captive portal come up for users (mac addresses) that the controller hasn't seen before?  In other words when a new mac address comes on the network, gets portaled, the user enters his AD credentials and get placed into a role and goes on his way.  Meanwhile the mac address gets stored locally on the controller and "whilelists" that mac so that the next day the user does not get captive portal'ed?

 

Rafael

This type of functionality would require an external AAA server. Do you have ClearPass? This is very easy to do in CPPM.

Hi Tim,

 

Thanks for the ultra quick reply!  I do not yet have clear pass.  How can it be done with an external aaa server without clear pass?  I am not oppossed to acquiring clear pass but if it can be done another way (NPS, freeradius) I would be game.

 

Thanks,

 

Rafael

You would need some type of SQL database to keep track of MAC addresses that your RADIUS server can query. You would then need a captive portal that can write back to the SQL databse. You could return a role of REGISTRATION-ROLE for devices that are not in the database, but MAC-AUTH-ROLE if they were in there.

 

ClearPass offers the most flexibility as all of this is in one package and can do much more like session tracking, bandwidth caps and device profiling.

 

tim

"You would then need a captive portal that can write back to the SQL databse"

 

*** Do you mean a non-Aruba based captive portal as the Aruba captive portal has no way to write back to the SQL database?

 

Thanks,

 

Rafael

---

@r.ertel wrote:

Hey All,

 

I am running into some limitations with my .1x implementation and looking for a different build out.  My idea is to combine captive portal and mac address authentication.  Is there a way to have the captive portal come up for users (mac addresses) that the controller hasn't seen before?  In other words when a new mac address comes on the network, gets portaled, the user enters his AD credentials and get placed into a role and goes on his way.  Meanwhile the mac address gets stored locally on the controller and "whilelists" that mac so that the next day the user does not get captive portal'ed?

 

Rafael

---

r.ertel,

 

What are your limitations?

 

cjoseph,

 

My limitations are that if a users AD creds are no good they'd be stuck in the logon role with no intructional options.  That's to say I could poke a hole in the logon role policies for access to the AD password reset tool we offer via https but a.) i see that as a security weakness and b.) if it were there the user still wouldn't know they can access it.

 

Thanks,

 

Rafael

r.ertel,

 

At our company, we have many users that connect via RAPs and 802.1x and we have the same issue with password resets.  In addition to having a portal, what they have done is send a user an email 10 days before his/her password expires so that it can be changed.  Do you have that capability?  It would just be a big step back if you forego encryption to deal with password resets...

 

You still have the option to put a link on your Captive Portal to do a password reset for AD users, which would be reachable by any device...

 

 

cjoseph,

 

We do actually already do email alerts (doesn't make it idiot proof though :(   ).  However there are two other problems: a.) peeps forgetting their passwords and b.) when new machines are deployed (mainly a Windows issue) the user has never logged in with their AD creds, and since they are in a logon role their machine cannot talk to AD to to log them in that first time.   I can poke a hole in the logon role fw policy but again that is a security issue, yea?

 

Rafael

r.ertel,

 

We try and advocate a machine authentication role of "allowall" so that the computer can do what it needs to at the ctrl-alt-delete screen.  That means that new users should be able to login, even on computers where they have not logged in before.  The security risk of a computer having access to the network at the ctrl-alt-delete screen is the same as the computer in a wired network.  The difference is, if the user does not pass authentication, he/she does not get in.  If the user logs into the computer with local credentials, those local credentials are not in AD and the computer is disconnected from the wireless.  Users who login to machine with cached, but expired/incorrect credentials are also disconnected from the network, because they cannot pass 802.1x on the wireless...

cjoseph,

 

I feel like we are getting closer to a resolution here but...

 

" If the user logs into the computer with local credentials, those local credentials are not in AD and the computer is disconnected from the wireless." 

 

What if that locally authenticated user is a war driver in my pakinging lot?  Let's say he associates to to my .1x ssid, as I understand it that would place him into the "logon" role which in this situation would allow that machine to communicate with AD.   What possibly harmful traffic would that "AD hole punch" allow this maliceous user to pass to possibly compromise our AD system?

 

Thanks,

 

Rafael

r.ertel,

 

The nature of 802.1x is that no traffic passes before successful authentication, regardless of the initial role.  No successful authentication = the role does not matter.

cjoseph,

 

So then poking a hole in the initial .1x role fw policy would not allow the computer to reach AD anyway?  

 

rafael

cjoseph,

 

"You still have the option to put a link on your Captive Portal to do a password reset for AD users, which would be reachable by any device..."

 

but with our present .1x model we do not use Captive Portal...

 

Rafael

Correct. The initial role in the AAA profile is not used in 802.1x. The initial role is for WLANs is to set a role upon association where the user does not or cannot authenticate ahead of time. The default 802.1x role is assumed upon successful authentication unless a server derived rule is in place.

cjoseph,  

 

Ok.  So doesn't that compound my problem?  How do you do the allow all machine auth and .1x?

 

Thanks,

 

Rafael

What are you using for your radius server?

NPS

Is your remote access policy in NPS specifying an AD group for authentication?  If so, you need to allow the "Domain Computers" AD group, OR remove the group AD group restriction...

I am waiting to hear back from my systems guy.  I believe however that when a user's creds are valid in AD NPS send the AD group name back to the controller and the controller associates the name of that group with the "authenticated" role...

 

Rafael

You can treat the computer like a user by simply checking for the "Domain Computers" group and also sending back the authenticated role.

Where does one config "checking for the "Domain Computers" group?"

 

Thanks,

 

Rafael

Please look at the document here:  http://community.arubanetworks.com/aruba/attachments/aruba/115/6113/1/Using+Microsoft+Windows+2008+Server+With+Aruba.pdf

Ok, that's what I thought you were talking about ;) 

 

So I think this will work for the windows and mac's issued to employees by us (they are joined to the domain during provisioned) but this will cause issues with personal mobile devices using .1x, yea?  Although I am not sure how concerned I am about that...

 

So let me get this straight.  By config'ing  “Enforce
 Machine
 Auth" on the controller and specifying "Domain Computers" in NPS the .1x user's computer whether Windows or Mac will be able to access AD the first time they are logging in to their new machine?

 

Rafael

Hold on. You should not use enforce machine authentication AND server derived rules together, because they are mutually exclusive. If you already have enforce machine authentication enabled, you should just make the machine authenticated role, authenticated and be done with it. Do not make any changes on your radius server.

I do not use enforce machine authentication presently.  Just to clarify let me restate which two problems I am trying to solve in my present .1x deployent:

 

1.)  When we hand out a freshly built machine to someone (they do not have local admin rights) they've never logged into it using their AD creds so they've never been cached so in order to be able to even log into their new machines the machine would have to be able to reach AD through the .1x SSID and of course it cannot right now.

 

2.)  If a user forgets his creds there is no way for him to use the password reset tool reachable via https on the AD box.

 

I would like to use .1x with a single SSID on the network for employees.

 

Rafael

Okay.

#1 is because successful machine authentication is not working. If you fix successful machine authentication you fix#1

#2 can only be fixed by the user managing the state of their password before it expires or with another device...

"Okay.

#1 is because successful machine authentication is not working. If you fix successful machine authentication you fix#1"

 

*** Ok, so does that mean I must config "Enforce Machine Authentication" on the controller with a proper "Machine Authentication: Default Machine Role"  and get rid of my AD Group derived role?

 

#2 can only be fixed by the user managing the state of their password before it expires or with another device...

 

*** Right, I guess that is what I meant by a limitation of my current .1x deployment

 

Rafael

R.ertel:

 

#1, you don't need to get rid of your user derived roles;  You just need to add another check to see if an incoming user is part of the "Domain Computers" AD group and send back and accept and possibly a different role that has allowall.  The only difference between a user and a computer authenticating is that the computer normally has a host/domain username and is part of the "Domain Computers" group.

 

#2, everyone has that "problem" and proactive password management is the answer for quite a few people.  If you fix machine authentication, when you try to login to a computer wirelessly, it will tell you the status of your password (expired, etc.), because the laptop will have an ip address from the Machine authentication and will be able to successfully communicate status back to the user.

"#1, you don't need to get rid of your user derived roles;  You just need to add another check to see if an incoming user is part of the "Domain Computers" AD group and send back and accept and possibly a different role that has allowall.  The only difference between a user and a computer authenticating is that the computer normally has a host/domain username and is part of the "Domain Computers" group."

 

*** So configuring NPS to do a check on "Domain Computers" AD group will allow accees through the controller to AD?  Not sure I understand that.  I think I just don't have a good grasp of .1x and how it is limited or not by preauth roles...

 

My wifes car just died gotta run and jump!

 

Thanks for all your input you'll probably see me again on Monday.

 

Rafael

 

 

Maybe you can help me understand .1x.  When a user associates to the .1x SSID what happens?  I was under the impression that the machine is allowed to send traffic through the controller based on the pre-auth role in my case it includes policies to allow dns and dhcp through.  How does the client send .1x traffic to the controller if the fw policy is only allowing dns and dhcp?  

How does adding a check in NPS for Domain Machines (based on its netbios name?) allow the flow of traffic to AD through the controller whilst in pre-auth mode?

 

Thanks,

 

rafael

Let's take a few steps back:

 

In 802.1x, there must be a successful authentication (not just association) for that device to be able to send any traffic.  In 802.1x the "logon" or pre-auth role in the AAA profile is not used, because no traffic is passed unless authentication takes place.

 

In machine authentication, a domain computer will attempt to authenticate via wireless 802.1x to the network (1) when it is booting up and (2) at client logout.  It will do so with "host/machinename" as the username and its SID or security identifier as the password.  When a computer has successfully completed machine authentication, it has an ip address at the ctrl-alt-delete prompt.  This ip address can be used to manage the device like any other wired computer, allow users who have not logged in before to login, and allow login scripts to run.  To the NPS radius server, machine authentication looks like any other 802.1x authentication, except the group membership for "host/machinename" users is "Domain Computers".  If your NPS rule (network policy)  is only allowing successful authentication from users in "Domain Users" for example, it will reject all attempted machine authentications and the machine will fail.

Awesome.  Thank you.  So pre-auth role doesn't effect users that associate with a .1x SSID?  It sounds like the controller then is being smart when .1x is implicated it allows .1x related traffic but nothing else?  How does it pass .1x traffic like in machine auth if prior to that ctrl auth del screen dhcp is not allowed?  Its gotta have an address to do anything right?

 

Thanks again!

 

rafael

The 802.1x specification allows a tunneled exchange of keys and credentials without allowing IP traffic.  That is uniform across all wireless LAN vendors.

 

that is simply genius thank you

 

rafael

cjoseph,

 

One last question.  With a Domain Computers check added will that prohibit the user of non-domain computers like mobile devices or will the mobile user still be able to pass their AD creds via the Domain Users check?

 

Thanks,

 

Rafael

NPS rules only stipulate that the device or user must be a member of one of the Windows Groups Specified, if Windows-Groups are used: http://technet.microsoft.com/en-us/library/cc731220(v=ws.10).aspx

 

You can just add "Domain Computers" group to your Windows Group Parameter.

 

Much thanks!

 

rafael

cjoseph,

 

We added the check for Domain Computers in NPS: see attachment, but no luck with .1x Computer auth (pre-user creds auth)  You mentioned in an early message:

 

 

"We try and advocate a machine authentication role of "allowall" so that the computer can do what it needs to at the ctrl-alt-delete screen."

 

Does that mean I need to config a separate role on the controller for Domain Computer authentication and an additional OU association in AD?

 

Thanks,

 

Rafael

domain computers should be in the windows groups, NOT machine groups.

cjosesph,

 

I asked my systems guy to make the change and now it appears as in this attachment:  but still no luck.  Does the fact that he has two "Windows Groups" prevent it from working correctly?

 

Thanks,

 

Rafael

 

 

should look like this:

 

It should look like this:

 

 Do you see any failures in the eventviewer of devices with host/domain as the username?

 

We did not see any failures.  We will reconfig the check though.   Thanks.

 

Rafael

Are your laptops configured to machine or user authentication?

ooooh, that I don't know.  but if they get configured to machine auth will I loose user auth and their usernames showing up in the controller?  if I just see the machine name I will not know who they are....  let me see how we have them set.

 

Rafael

Windows Domain computers that are configured correctly only do machine authentication at the ctrl-alt-delete prompt.  They do user authentication when the user is attempting to log in.

 

Ok so at the cont.alt.dlt screen state I should see the computer name show up in the controller and then after user auth I would see their username, yea?

So I am not seeing the computer name on the controller during ctr.alt.delete, and when we try their cred the pc throws an error like " "There are currently no logon servers available to service the logon request."

 

Rafael

 

Here are instructions on how to configure it for Windows 7:  http://technet.microsoft.com/en-us/library/dd759219.aspx

 

EDIT:  Forget the link.  This is how your Windows 7 client WLAN settings should look:

 

 

 

Cool thanks!  I definately have to check to see how this is being configured when we set up new pc's.

 

Rafael

cjoseph,

 

I have confirmed those are indeed the settings we are using...

 

rafael

... am I missing something in the controller config...?

 

rafael

No. You need to log a laptop out and watch the radius event viewer.

By what means can I track the specific machine in NPS?

 

rafael

In NPS you look under Event viewer > Server Roles> NPS> to see the NPS-Specific events.  You might see a computer with a username host/<name of host> attempting to authenticate.

 

viewing... thanks

 

rafael

cjoseph,

 

Ok so you mentioned in an earlier post that you have a role in the controller for Domain Computers.  I do not.  I only have a role for Domain Users which takes the "Employee" string and matches it to the "authenticated" role.  I am guessing I am also going to need to match whatever NPS replies to the controller for Domain Computer auth attempts to a role, yea?

 

 

Server Rules Priority Attribute Operation Operand Type Action Value Validated Actions 1 Class contains Employee String set role authenticated Yes

 

Thanks,

 

Rafael

 

 

If you do not send an attribute, the computer will simply get the default 802.1x role in the AAA profile.  Did you see any users with the username host/computer attempt to authenticate in the event viewer?

 

yes, saw authentication attempts in NPS and saw the deny in controller logs.  however after reading some training material I realized my initial role is set to "authenticated" and the default was set to "guest" they are now both set for "authenticated"

So what does NPS send back to the controller when AD knows about the Domain Computer?  

 

"If you do not send an attribute, the computer will simply get the default 802.1x role in the AAA profile."

 

So which is the "proper" way to do this for Domain Computers, have NPS send an attribure or let it end up in the default role?

 

Thanks,

 

Rafael

Attempts in the Radius log, but what did the radius server respond?  That is important.  The controller just takes what NPS says, so we have to look all the way to the bottom of the eventviewer reject message to see why NPS rejected the request.

ok looking now...

Yup:

 

ReasonCode 48 Reason The connection request did not match any configured network policy. LoggingResult Accounting information was written to the local log file.

 

Now that is because we broke nps yesterday trying to add the Domain Computers not sure why.  So if we had a check for Domain Computers on that NPS that would be a "matched network policy?"  If so what would be the behavior with no additional attributes configured?

 

Thanks,

 

Rafael