cancel
Showing results for 
Search instead for 
Did you mean: 

EAC - domain user over domain computer

EAC - domain user over domain computer

EF
Contributor

Hi team

I'm confused about this scenery and how EAC implement it.

In a windows domains using EAP-PEAP auth, we want auth user over domains machines to avoid BYOD and give access to unmanage devices.

But as I know 802.1x supplicant can´t send both credentials at the same time (when is configured as "user o Computer" credentials), so I suppose that:

1.- Before the user log in the machine, it sends the machine credentials.

2.- After user login, it sends the user credentials.

And here is my dout, how does EAC to match that the users credentials comes from the machine previously authenticated?

In other product, IGNITION server, I rememeber that after a machine was authenticated this information was store in a local databese for N days (configurable) and all the next user authentications from this machine during these N days were valid, but EAC I dont know how handle this.

I would like to understand this because I have users that only send the user credentials and are matched on the correct rule (domain user over domain machine ) although the machine never sends it credentials, so I can´t undertand how the EAC know is that.

Regards

EF

1 ACCEPTED SOLUTION

Ryan_Yacobucci
Valued Contributor

Hello,

Control can leverage a feature that can perform LDAP lookups on the hostname that was learned for the device.

Control has separate fields for "Username" and "Hostname" and can perform lookups on both to match a criteria.

When the user logs into the machine EAP-PEAP will send the credential for the user, and Control can perform an LDAP lookup for the username provided in the EAP-PEAP authentication, as well as a lookup for the hostname learned through reverse DNS lookups to make sure the device also exists in the domain.

You can find this criteria by creating a new end system group:

Ryan_Yacobucci_0-1669037054743.png

There are a couple of things that need to be in place for this to work:

1. The default deployment using LDAP host group rules relies on reverse DNS lookups to obtain the fully qualified hostname of the device. The FQDN of the end system is required as per the default "Host Search" attributes Control wanted to use dnsHostName, which is always fully qualified.

Ryan_Yacobucci_1-1669037430706.png

To meet the LDAP host group criteria there are a lot of moving parts:

Authentication of the end system MUST be allowed to occur BEFORE the LDAP host group criteria can be available for use. To meet this criteria a number of things must be learned about the end system before it can be matched. This is a "chicken or egg" type scenario. Control must learn IP address and perform reverse DNS lookup before the FQDN hostname can be learned. If this is not performed the criteria will not be met.

This works well in a Computer+User authentication environment as long as the end system always performs machine authentication on boot and all necessary information is learned before the user attempts to login.

You would need two rules:
1. Machine authentication rule set to look for either a host/* username, or an LDAP attribute. (If LDAP attribute make sure AAA exists to handle lookups for servicePrincipalName).
2. A rule to handle User lookups with domain hostnames.
User Criteria: Any LDAP criteria Desired
End System Criteria: LDAP Host group set to "Exists"

Ryan_Yacobucci_2-1669037797629.png


The flow for this type of set up occurs like this:

1. User powers up end system
2. End system performs Machine Authentication and displays user with sign in screen.
3. The Machine Authentication hits a rule in control that Allows access to at least DHCP/DNS services.
4. End System gets DHCP Address
5. Microsoft Reverse DNS zone is populated with IP to FQDN mapping.
6. Control Performs IP Address Resolution and learns correct IP address of end system
7. Control performs reverse DNS lookup and learn the FQDN of the end system
8. User logs into end system with User Credentials
9. Control now has the information required to match the LDAP host group rule, and can put the end system in a rule that evaluates both the username LDAP criteria from EAP-PEAP and that the learned hostname exists as a domain joined computer.


Thanks
-Ryan

View solution in original post

1 REPLY 1

Ryan_Yacobucci
Valued Contributor

Hello,

Control can leverage a feature that can perform LDAP lookups on the hostname that was learned for the device.

Control has separate fields for "Username" and "Hostname" and can perform lookups on both to match a criteria.

When the user logs into the machine EAP-PEAP will send the credential for the user, and Control can perform an LDAP lookup for the username provided in the EAP-PEAP authentication, as well as a lookup for the hostname learned through reverse DNS lookups to make sure the device also exists in the domain.

You can find this criteria by creating a new end system group:

Ryan_Yacobucci_0-1669037054743.png

There are a couple of things that need to be in place for this to work:

1. The default deployment using LDAP host group rules relies on reverse DNS lookups to obtain the fully qualified hostname of the device. The FQDN of the end system is required as per the default "Host Search" attributes Control wanted to use dnsHostName, which is always fully qualified.

Ryan_Yacobucci_1-1669037430706.png

To meet the LDAP host group criteria there are a lot of moving parts:

Authentication of the end system MUST be allowed to occur BEFORE the LDAP host group criteria can be available for use. To meet this criteria a number of things must be learned about the end system before it can be matched. This is a "chicken or egg" type scenario. Control must learn IP address and perform reverse DNS lookup before the FQDN hostname can be learned. If this is not performed the criteria will not be met.

This works well in a Computer+User authentication environment as long as the end system always performs machine authentication on boot and all necessary information is learned before the user attempts to login.

You would need two rules:
1. Machine authentication rule set to look for either a host/* username, or an LDAP attribute. (If LDAP attribute make sure AAA exists to handle lookups for servicePrincipalName).
2. A rule to handle User lookups with domain hostnames.
User Criteria: Any LDAP criteria Desired
End System Criteria: LDAP Host group set to "Exists"

Ryan_Yacobucci_2-1669037797629.png


The flow for this type of set up occurs like this:

1. User powers up end system
2. End system performs Machine Authentication and displays user with sign in screen.
3. The Machine Authentication hits a rule in control that Allows access to at least DHCP/DNS services.
4. End System gets DHCP Address
5. Microsoft Reverse DNS zone is populated with IP to FQDN mapping.
6. Control Performs IP Address Resolution and learns correct IP address of end system
7. Control performs reverse DNS lookup and learn the FQDN of the end system
8. User logs into end system with User Credentials
9. Control now has the information required to match the LDAP host group rule, and can put the end system in a rule that evaluates both the username LDAP criteria from EAP-PEAP and that the learned hostname exists as a domain joined computer.


Thanks
-Ryan

GTM-P2G8KFN