1 ACCEPTED SOLUTION
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:
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.
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"
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
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:
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.
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"
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
