EAP-TLS and LDAP with Windows Server 2012R2 Native Functional Level

[Matthew Newton]

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 at 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 at 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 at rsd.net"
> (5) eap_tls: caching TLS-Client-Cert-Issuer := "/C=US/ST=California/L=Lake Forest/O=RSD/emailAddress=telsberry at 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 at 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 at le.ac.uk>