Wireless Access

I have enabled Machine Authentication on my IAS servers to facilitate a pre-logon role for my Active Directory users.
Basically when a Computer is authenticated under the "Allow Domain Computers" IAS Policy the Aruba Controller assigns a user role I have named "AD-Computer".

I would like to create a policy for this AD-Computer Role that opens only those ports required for the user to login to my Active Directory. Anyone have a list of ports/services that I need to allow?

Thanks in advance.

I personally think that the computer-only rule should be "allowall". It is the functional equivalent of plugging your domain computer into a physical port. If a user cannot log into it, the user cannot send traffic via the machine, so just allow the computer to do its own thing from a firewall standpoint. Domain Machines are meant to be trusted, when users are not logged into them.

Thanks cjoseph

"allowall" is actually the policy I have in place currently. I just wondered if it would be advantageous to lock it down a little more.

Still from a curiosity point of view, if anyone knows which ports are essential for AD Users to logon, I would still like to have this knowledge.:)

---

---

Thanks cjoseph

"allowall" is actually the policy I have in place currently. I just wondered if it would be advantageous to lock it down a little more.

Still from a curiosity point of view, if anyone knows which ports are essential for AD Users to logon, I would still like to have this knowledge.:)

---

http://support.microsoft.com/?id=832017 and http://support.microsoft.com/kb/224196/ provide a bunch of that data.

---

Thanks for the great info jeffersonc, it has made me realize that the more I look into this the more sense Colin's suggestion of "Allow all" makes sense. :)

Cheers,

---

Thanks for the great info jeffersonc, it has made me realize that the more I look into this the more sense Colin's suggestion of "Allow all" makes sense. :)

Cheers,

---

I'm dealing with this precise issue right now, and have added the recommended ports to allow AD machines to login, and verified using the 'firewall hits' and 'client status' views in the admin gui to verify the rules are sufficient. There are two reasons I can think of for not using "allow-all":

1. However remote, there is always the possibility that a domain computer can be compromised and become a threat.

2. I don't like using wide open ACLs for anything beyond admin use. Our campus LAN still uses VMPS for wired ports, which is trivial to spoof, so ensuring per VLAN ACLs are tight is a necessity.

But I also have a question regarding machine auth with IAS: How secure is it? If an attacker can gain knowledge of a valid AD machine name and SID, how difficult is it to spoof the machine auth process? Without an answer to this, I would be *very* cautious about an "allow-all" approach.

---

I'm dealing with this precise issue right now, and have added the recommended ports to allow AD machines to login, and verified using the 'firewall hits' and 'client status' views in the admin gui to verify the rules are sufficient. There are two reasons I can think of for not using "allow-all":

1. However remote, there is always the possibility that a domain computer can be compromised and become a threat.

2. I don't like using wide open ACLs for anything beyond admin use. Our campus LAN still uses VMPS for wired ports, which is trivial to spoof, so ensuring per VLAN ACLs are tight is a necessity.

But I also have a question regarding machine auth with IAS: How secure is it? If an attacker can gain knowledge of a valid AD machine name and SID, how difficult is it to spoof the machine auth process? Without an answer to this, I would be *very* cautious about an "allow-all" approach.

---

An allow-all in the machine auth role would be no worse than you having a computer plugged into your wired network, but not logged in. A device is only in this state, when it is at the ctrl-alt-delete screen. I want to say that nobody knows the SID, because it is completely random and negotiated by the computer with the domain. A user is more likely to compromise a username and password rather than machine credentials that are never revealed. Even if they compromised those credentials, they would still have no rights, because computers do not have any rights to user resources. It is much easier to plug into an open wired port than to exploit.

Your exploit path looks like this:

- Somehow get machine credentials that are completely random and never revealed
- Put them into a consumer device to get on the network
- Your user is now just as good as plugging into a physical port, which is easier

OR:

- Somehow hack into a computer locally
- Local credentials that were used to get into the computer will fail on the domain so the connection will be dropped
- Give up and plug into a wired port

Compromising machine credentials, however unlikely, only gets you access to the LAN. You might be able to access resources that a physical machine can on a domain, but not a user can access on your domain, but it does not elevate you to more than that.

The allow all is only to permit the computer's domain activity so that logging in and getting a login script is not a problem. It keeps you from having to update the the ACLs with different ports and hosts everytime you add a domain controller, or MSFT changes some protocol and it also allows you to update the computer with antivirus, MS patches, etc without necessarily compromising physical security and removing some of the complexity.

When I've configured machine authentication is has almost exclusively been to provide network connectivity for their pre-logon scripts not to actualy verify whether it's a trusted client. In fact, most clients I see still have access to their network properties.

 

In that light, when you leave the machine-auth role as allow-all.. doesn't that allow those internal people that set their wlan profile to authenticate machine-only and then logon with a local user or even a domain user while remaining in that allow-all role?

In a perfect world, that would all be managed via group policy, so the user would not be able to change his/her settings. If a user *could* change his device to machine-only, that device would have to have a legitimate machine account on the domain to attach.  You cannot simply authenticate as a user to machine authenticate.  A device that authenticates in the machine context still only has domain rights to do what a computer would do to maintain itself.  

While I allow all to the local network I do block access externally. So, it can still authenticate and access whatever network resources ot needs to properly log, etc., but there is no access to external servers, or sites.

 

---

An allow-all in the machine auth role would be no worse than you having a computer plugged into your wired network, but not logged in. A device is only in this state, when it is at the ctrl-alt-delete screen. I want to say that nobody knows the SID, because it is completely random and negotiated by the computer with the domain. A user is more likely to compromise a username and password rather than machine credentials that are never revealed. Even if they compromised those credentials, they would still have no rights, because computers do not have any rights to user resources. It is much easier to plug into an open wired port than to exploit.

Your exploit path looks like this:

- Somehow get machine credentials that are completely random and never revealed
- Put them into a consumer device to get on the network
- Your user is now just as good as plugging into a physical port, which is easier

OR:

- Somehow hack into a computer locally
- Local credentials that were used to get into the computer will fail on the domain so the connection will be dropped
- Give up and plug into a wired port

Compromising machine credentials, however unlikely, only gets you access to the LAN. You might be able to access resources that a physical machine can on a domain, but not a user can access on your domain, but it does not elevate you to more than that.

The allow all is only to permit the computer's domain activity so that logging in and getting a login script is not a problem. It keeps you from having to update the the ACLs with different ports and hosts everytime you add a domain controller, or MSFT changes some protocol and it also allows you to update the computer with antivirus, MS patches, etc without necessarily compromising physical security and removing some of the complexity.

---

I understand that compromising the machine auth process may not be trivial, but the possibility exists. At that point, a wireless device has "allow-all" to the network, which is more than just plugging into a wired port will provide. We use VMPS for wired port VLAN assignment, which is very weak, but when combined with limiting VLANs to specific edge switch ports, is reasonably secure, in that ports in highly public areas can *never* get onto a VLAN with too much access.

Careful use of aliases for servers, and service definitions for ports in the ArubaOS firewall can make the maintenance of changes to your AD domain servers much easier.