On Tue, Oct 25, 2016 at 08:15:11PM -0400, Travis via Freeradius-Users wrote:

...

I was bitten by that too. Try changing it to:

if (&Ldap-Group == "WiFi")

I made the change recommended and it still results in certificates being rejected with

(6) if (&Ldap-Group == "WiFi") -> FALSE

You need to read the debug output and see what it is actually doing.

Is using certificates for computers mutually exclusive of being able to use Active Directory username and passwords?

No. But you need to work out what you want to do, and configure accordingly. Looking at your debug output: On Mon, Oct 24, 2016 at 05:07:06PM -0400, Travis via Freeradius-Users wrote:

Waking up in 4.8 seconds. (5) Received Access-Request Id 32 from 10.10.2.5:32809 to 10.10.0.238:1812 length 196 (5) User-Name = "host/TElsberry10-Tab"

so a Windows host type User-Name.

(5) NAS-IP-Address = 10.10.2.5 (5) NAS-Identifier = "dc9fdb7003d4" (5) NAS-Port = 0 (5) Called-Station-Id = "DC-9F-DB-70-7A-82:RSD-TABLET" (5) Calling-Station-Id = "88-53-2E-7C-FD-DA" (5) Framed-MTU = 1400 (5) NAS-Port-Type = Wireless-802.11 (5) Connect-Info = "CONNECT 0Mbps 802.11b" (5) EAP-Message = 0x023600060d00 (5) State = 0xe1b5c235e583cf190cf7c580ecd5b37c (5) Message-Authenticator = 0xb44d62e8c23068a4e0c13849488f835d (5) session-state: No cached attributes

(5) eap_tls: [eaptls process] = success (5) eap_tls: caching TLS-Cert-Serial := "a793227a08ee79ec" (5) eap_tls: caching TLS-Cert-Expiration := "400316212404Z" (5) eap_tls: caching TLS-Cert-Subject := "/C=US/ST=California/L=Lake Forest/O=RSD/emailAddress=telsberry@rsd.net/CN=RSD RADIUS Certificate Authority" (5) eap_tls: caching TLS-Cert-Issuer := "/C=US/ST=California/L=Lake Forest/O=RSD/emailAddress=telsberry@rsd.net/CN=RSD RADIUS Certificate Authority" (5) eap_tls: caching TLS-Cert-Common-Name := "RSD RADIUS Certificate Authority" (5) eap_tls: caching TLS-Client-Cert-Serial := "9c" (5) eap_tls: caching TLS-Client-Cert-Expiration := "260822222730Z" (5) eap_tls: caching TLS-Client-Cert-Subject := "/C=US/ST=California/O=RSD/CN=TElsberry10-Tab/emailAddress=TElsberry10-Tab@rsd.net" (5) eap_tls: caching TLS-Client-Cert-Issuer := "/C=US/ST=California/L=Lake Forest/O=RSD/emailAddress=telsberry@rsd.net/CN=RSD RADIUS Certificate Authority" (5) eap_tls: caching TLS-Client-Cert-Common-Name := "TElsberry10-Tab"

Certificate Common Name is probably more reliable (less prone to spoofing) and already in the right format in your case.

(5) eap_tls: caching TLS-Client-Cert-X509v3-Extended-Key-Usage += "TLS Web Client Authentication"

(5) if (Ldap-Group == "WiFi") { (5) Searching for user in group "WiFi" rlm_ldap (ldap): Reserved connection (0) (5) EXPAND (sAMAccountName=%{%{Stripped-User-Name}:-%{User-Name}}) (5) --> (sAMAccountName=host/TElsberry10-Tab)

Doing an LDAP search, looking for sAMAccountName equal to "host/TElsberry10-Tab". This is probably not right. sAMAccountName for hosts is usually something more like TElsberry10-Ta$. Look in your LDAP to check. So this is probably why you don't get a match.

(5) Performing search in "dc=rsdtc,dc=com" with filter "(sAMAccountName=host/TElsberry10-Tab)", scope "sub" (5) Waiting for search result... rlm_ldap (ldap): Rebinding to URL ldap://ForestDnsZones.RSDTC.COM/DC=ForestDnsZones,DC=RSDTC,DC=COM rlm_ldap (ldap): Waiting for bind result... rlm_ldap (ldap): Rebinding to URL ldap://DomainDnsZones.RSDTC.COM/DC=DomainDnsZones,DC=RSDTC,DC=COM rlm_ldap (ldap): Waiting for bind result... rlm_ldap (ldap): Rebinding to URL ldap://RSDTC.COM/CN=Configuration,DC=RSDTC,DC=COM rlm_ldap (ldap): Waiting for bind result... rlm_ldap (ldap): Bind successful rlm_ldap (ldap): Bind successful rlm_ldap (ldap): Bind successful (5) Search returned no results

Not unexpected. Look in your LDAP database to see what is actually there, for both hosts and normal users. Then configure the ldap filters and other options in mods-enabled/ldap to look for the correct data. Feed the filters into e.g. ldapsearch on the command line to make sure that they come back with the right result. If you're doing LDAP lookups for both users and hosts, then you may find it easier to configure two instances of the ldap module, one for each, and then call whichever is appropriate. For example, by looking at EAP-Type to determine whether the EAP type is PEAP or EAP-TLS. Personally (and what I do here) I would use the check-eap-tls virtual server so you can check the actual contents of the certificate with LDAP, rather than relying on the contents of the User-Name attribute. Which a clients could easily spoof, but they can't spoof the certificate subject. For plain users, just call "ldap" in the inner tunnel as usual. Possibly wrapped around with a if EAP-Type == PEAP so it doesn't get called for hosts (check-eap-tls won't get called for PEAP as there is no client certificate, so you don't need that the other way around). But essentially - look at the LDAP lookups that FreeRADIUS is doing, and then go update the configuration so it does the right lookups with the data it has available. Matthew -- Matthew Newton, Ph.D. <mcn4@leicester.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>