ExtremeWireless (WiNG)

Hi,

I try to follow the GTAC knowledge below:
https://extremeportal.force.com/ExtrArticleDetail?an=000082958

but its not working in my setup. what is "802.1x Placeholder" rule? based on the procedure it only the authentication is change to 802.1x. and no changes on other option

appreciate if someone have screenshots of this setting.

thanks!

Hi,

I believe you can do it by two rules:
rule 1 (higher position = higher priority) will have conditions:
authentication is 802.1x
endsystem group is domain computer
apply profile "authorized domain computer"
Rule 2 (lower position = lower priority than rule 1) will have condition:
authentication is 802.1X
apply profile "restricted access to basic services"

first time the computer connects will go through rule 2. then computer will update DNS records and hostname resolution will reauthenticate the endsystem. reauthentication will hit the rule 1.

"endsystem group is domain computer" does verify hostname in LDAP

----

another option how to solve your issue (from my point of view more secure): use EAP-TLS = provision your domain computers with certificates. if the EAP-TLS is used then you know the device is under domain control.

Another option is to use PEAP and verify the username is "host/*" then you know it is computer in the domain

---

good luck

Z.

Hello,

I will just clarify Zdenek's response for future use:

The 802.1x LDAP host group rule solution requires a placeholder rule because DHCP/DNS must perform specific actions before the rule can work.

The LDAP host group rule works like this:

In order to match the "LDAP host group rule" criteria of "exists" the NAC must perform an LDAP lookup of the FQDN of the end system the result of the query will satisfy the "exists" criteria.

In order to know the FQDN of the end system for lookup to the Active Directory the NAC must be able to perform a reverse DNS lookup of the IP address of the end system, and have DNS respond back with the FQDN of the device.

In order for the NAC to know the IP address to perform the reverse DNS lookup, the NAC must complete IP to MAC resolution

In order for the NAC to complete MAC to IP address resolution the client has to have an IP address.

In order for the client to have an IP address it must have received an authorization from a _Previous authentication_ that allows it to receive an IP address.

The role of the placeholder rule is so that an unknown client can get on the network, obtain an IP address, complete the process, and if it matches the LDAP host group rule criteria it will get elevated access. Without the placeholder the client could fall into a rule that gives no access to DHCP and the entire solution will generally not work. They only need to have DHCP/DNS access.

The entire LDAP host group rule criteria process flow is the following:

1. Client connects to network
2. NAC bypasses rule with "LDAP host group criteria" and matches the placeholder (which has DNS/DHCP allowed)
3. Client completes authentication/authorization and gets an IP address, DHCP updates DNS with new reverse record for the client
4. NAC sees DHCP request and updates hostname with the hostname, but NOT the FQDN (generally)
5. NAC completes MAC to IP resolution
6. NAC attempts a reverse DNS lookup using the obtained IP address
7. DNS returns FQDN of the end system
8 NAC updates hostname field with FQDN of the end system
9 NAC internally decides to re-auth the client (Logic in the system kicks in if LDAP host group rule is in use and the hostname field changes causing a decision to re-auth)
10. Client is disconnect/re-auths (accordingly) and new authentication event occurs
11. NAC can then use the known FQDN of the end system to perform and LDAP lookup to match the "LDAP host group" criteria and the user will get elevated access.

This generally only happens the first time a client is connected and seen, or if for any reason we lose the FQDN of the end system.

Thanks
-Ryan

Hi Folks,

Is there any alternative to avoid reverse DNS lookup?
I'm doing a huge NAC deployment. The rule defined to validade users and computers in the AD are not working and i figured out the DNS reverse zones are not being updated by the DHCP. Any solution?
Many thanks for all.

Luís Oliveira

Hi,

 

I have similar problems.

I also tried to follow the GTAC-advise, however I have no clue how to correctly configure 

“user is in Domain Users AND end-system is in Domain Devices”

 

Can someone explain/show for dummies?

 

Thank you!

Hello,

Note: This is an example that REQUIRES Machine + User authentication to work successfully. No BYOD 802.1x is considered either. 

Here is an example set of 2 rules: 

This represents:

A user who has logged into a domain machine.
A domain Machine who has booted up but nobody logged in.

Here is the configuration for Domain User and Machine: 

 

User group: 

 

End System Group: 

 

 

To match this rule:

 

1. 802.1x authentication must be used2
2. Username LDAP lookup must return the criteria in the “Domain user” group (Per your requirements)
3. Device’s HOSTNAME must also be found in an LDAP query. The “End System: LDAP host group” exists criteria causes NAC to perform an LDAP lookup of the device’s HOSTNAME to match the criteria. 

 

NAC learns hostnames from either DHCP fingerprinting or reverse DNS lookup of the IP address (IP address must be learned)

 

In order for NAC to receive DHCP information to determine hostname/IP address the client MUST be allowed on the network with a minimum level of access to gain an address and DHCP to occur. 

 

Because this rule contains criteria requirements that are NOT available when the client first connects you must build a rule to catch them and allow that minimum level of access in order for the process to function normally. In our example this is the Domain Machine rule. 

NOTE: If you do not build rules this specific way a “Placeholder” rule is necessary to provide a minimum level of access to get an IP address. Without this “Placeholder” Control will never learn the hostname of the device in order to match the LDAP host group criteria.

 

Process flow for different types of logins seen: 

 

1. A brand new Domain Machine boots up on the network and no user logs in.
   
   A  brand new, never before seen domain machine is booted up, end user goes to get coffee so no user login occurs. 
   
   Domain Machine will authentication with computer account that has following format:
   host/hostname.domain
   
   Domain Machine User: Username group is used to catch domain machines: 

   

   
   Domain Machine access rule is hit. Domain Machine access is provided.
   
    
2. In this state Control will learn hostname from DHCP request packet (Must configure control appliance as Bootp relay on routers)
   
   Control will also learn IP address 
   
   Control will user IP address to perform reverse DNS lookup to obtain FQDN (dNSHostname) of the end system.
   
    
3. User comes back from coffee and logs into computer
   
   sAMAccount name provided through 802.1x login. This will satisfy the Domain User criteria.
   
   Because NAC was able to learn the hostname in the above process flow the LDAP host group criteria will be matched and used. 
   
   The Domain User + Domain Machine rule will be matched and used. 

 

Important Note: The hostname resolution in step 2 is a requirement. If NAC cannot learn hostname this will never be matched. This configuration assumes all domain machines will initially always start in a machine authenticated state in order for this learning process to occur.

In some situations a “Placeholder” rule is necessary to provide temporary access in order to learn this information and match the rule. If you find you are not able to match the LDAP host group rule because the hostname is NOT learned this may be your issue. 

 

There is also a variation on this configuration where “name” is used for “host search attribute” in your LDAP configuration and “Use Fully Qualified Domain Name” is de-selected instead of “dNSHostname” in order to not require the reverse DNS zone and reverse lookup functionality to obtain FQDN for dNSHostname attribute. 

 

Thanks

-Ryan