I've set up the LDAP bind how I think it should be done and it seems to be binding correctly. It, however, is not successfully authenticating a user. This is the radiusd -X output:

Ready to process requests.
rad_recv: Access-Request packet from host 10.10.20.40 port 1645, id=15,
length=95
            NAS-IP-Address = 10.10.20.40
            NAS-Port = 2
            NAS-Port-Type = Virtual
            User-Name = 'user'
            Calling-Station-Id = '10.10.1.35'
            User-Password = 'password'
(1) # Executing section authorize from file /usr/local/etc/raddb/sites-
enabled/default
(1)   authorize {
(1)   filter_username filter_username {
(1)   ? if (User-Name != "%{tolower:%{User-Name}}")
(1)    expand: "%{tolower:%{User-Name}}" -> 'user'
(1)   ? if (User-Name != "%{tolower:%{User-Name}}") -> FALSE
(1)   ? if (User-Name =~ / /)
(1)   ? if (User-Name =~ / /) -> FALSE
(1)   ? if (User-Name =~ /@.*@/ )
(1)   ? if (User-Name =~ /@.*@/ ) -> FALSE
(1)   ? if (User-Name =~ /\\.\\./ )
(1)   ? if (User-Name =~ /\\.\\./ ) -> FALSE
(1)   ? if ((User-Name =~ /@/) && (User-Name !~ /@(.+)\\.(.+)$/))
(1)   ? if ((User-Name =~ /@/) && (User-Name !~ /@(.+)\\.(.+)$/)) -> FALSE
(1)   ? if (User-Name =~ /\\.$/)
(1)   ? if (User-Name =~ /\\.$/) -> FALSE
(1)   ? if (User-Name =~ /@\\./)
(1)   ? if (User-Name =~ /@\\./) -> FALSE
(1)   } # filter_username filter_username = notfound
(1)   [preprocess] = ok
rlm_ldap (ldap): Reserved connection (4)
(1) ldap :      expand: "(uid:%{%{Stripped-User-Name} :- %{User-Name}})" ->
'(uid=user)'
(1) ldap :            expand: "ou=DOMAIN Users,dc=DOMAIN,dc=com" -> 'ou=DOMAIN
Users,DC=DOMAIN,DC=com'
(1) ldap : Performing search in 'ou=DOMAIN Users,dc=DOMAIN,dc=com' with
filter '(uid=user)'
(1) ldap : Waiting for search result...
(1) ldap : User object found at DN "CN=Joe Bloggs,OU=GROUP,OU=DOMAIN
Users,DC=DOMAIN,DC=com"
rlm_ldap (ldap): Released connection (4)
rlm_ldap (ldap): Opening additional connection (5)
rlm_ldap (ldap): Connection to domaincontroller.DOMAIN.com:389
rlm_ldap (ldap): Waiting for bind result...
rlm_ldap (ldap): Bind successful
(1)   [ldap] = ok
(1)   [chap] = noop
(1)   [mschap] = noop
(1)   [digest] = noop
(1) suffix : No '@' in User-Name = "user", looking up realm NULL
(1) suffix : No such realm "NULL"
(1)   [suffix] = noop
(1) eap : No EAP-Message, not doing EAP
(1)   [eap] = noop
(1)   [files] = noop
rlm_ldap (ldap): Reserved connection (5)
(1) ldap :      expand: "(uid=%{%{Stripped-User-Name}:-%{User-Name}})" ->
'(uid=user)'
(1) ldap :      expand: "ou=DOMAIN Users,dc=DOMAIN,dc=com" -> 'ou=DOMAIN
Users,DC=DOMAIN,DC=com'
(1) ldap : Performing search in 'ou=DOMAIN Users,dc=DOMAIN,dc=com' with
filter '(uid=user)'
(1) ldap : Waiting for search result...
(1) ldap : User object found at DN "CN=Joe Bloggs,OU=GROUP,OU=DOMAIN
Users,DC=DOMAIN,DC=com"
rlm_ldap (ldap): Released connection (5)
(1)   [ldap] = ok
(1)   [expiration] = noop
(1)   [logintime] = noop
(1) WARNING: pap : No "known good" password found for the user. Not setting
Auth-Type.
(1) WARNING: pap : Authentication will fail unless a "known good" password is
available.
(1)   [pap] = noop
(1)  } # authorize = ok
(1) ERROR: No Auth-Type found: rejecting the user via Post-Auth-Type = Reject
(1) Failed the authenticate the user.
(1) Using Post-Auth-Type Reject
(1) # Executing group from file /usr/local/etc/raddb/sites-enabled/default
(1)  Post-Auth-Type REJECT {
(1) attr_filter.access_reject : expand: "%{User-Name}" -> 'user'
(1) attr_filter.access_reject : Matched entry DEFAULT at line 11
(1)  [attr_filter.access_reject] = updated
(1) eap : Request didn't contain an EAP-Message, not inserting EAP-Failure
(1)  [eap] = noop
(1)  remove_reply_message_if_eap remove_reply_message_if_eap {
(1)   ? if (reply:EAP-Message && reply:Reply-Message)
(1)   ? if (reply:EAP-Message && reply:Reply-Message) -> FALSE
(1)   else else {
(1)    [noop] = noop
(1)   } # remove_reply_message_if_eap remove_reply_message_if_eap = noop
(1)  } # Post-Auth-Type REJECT = updated
(1) Finished request 1.
Waking up in 0.3 seconds.
Waking up in 0.6 seconds.
(1) Sending delayed reject
Sending Access-Reject of id 15 from 10.10.20.26 port 1812 to 10.10.20.40 port
1645
Waking up in 4.9 seconds.


Thanks
-Luke

On Tue, Jan 28, 2014 at 11:57 AM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:

On 28 Jan 2014, at 11:35, Luke Ramsden <lukermsdn@gmail.com> wrote:

> I have experimented with using LDAP bind before and encountered problems (see link below). One of the responses on the thread said I must use MSCHAPv2 if I do not have plaintext passwords in AD - which I do not:
>
>          "Unless you are storing passwords in Active Directory in plain text or you want to use Kerberos authentication, you will have to use MSCHAPv2 (or its EAP equivalent, EAP-MSCHAPv2)."
>
> Previous thread relating to LDAP auth: http://freeradius.1045715.n5.nabble.com/LDAP-Active-Directory-Authentication-Issue-td5724001.html#a5724014

Stefan's answer was slightly misleading.

If you have the Cleartext-Password from the user you can attempt to bind as the user again the AD LDAP interface and use the bind result to determine whether to reject or allow the user.

Arran Cudbard-Bell <a.cudbardb@freeradius.org>
FreeRADIUS Development Team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html



On Tue, Jan 28, 2014 at 11:57 AM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:

On 28 Jan 2014, at 11:35, Luke Ramsden <lukermsdn@gmail.com> wrote:

> I have experimented with using LDAP bind before and encountered problems (see link below). One of the responses on the thread said I must use MSCHAPv2 if I do not have plaintext passwords in AD - which I do not:
>
>          "Unless you are storing passwords in Active Directory in plain text or you want to use Kerberos authentication, you will have to use MSCHAPv2 (or its EAP equivalent, EAP-MSCHAPv2)."
>
> Previous thread relating to LDAP auth: http://freeradius.1045715.n5.nabble.com/LDAP-Active-Directory-Authentication-Issue-td5724001.html#a5724014

Stefan's answer was slightly misleading.

If you have the Cleartext-Password from the user you can attempt to bind as the user again the AD LDAP interface and use the bind result to determine whether to reject or allow the user.

Arran Cudbard-Bell <a.cudbardb@freeradius.org>
FreeRADIUS Development Team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html