Freeipa and Freeradius integration

Wed Apr 22 10:01:38 CEST 2015

Thanks so far, your help on this list is really good.

I have been looking further into what my server is telling freeradius.
I hope you can tell me what the setting needs to be if I am getting
these replies back. The ldapsearch I did uses the same credentials I
am using in the sites-enabled/ldap file.

Ldapsearch output (|grep userPass):
============================================================
userPassword:: e1NTSEF9Tk5***************************************ka0E9PQ=
============================================================

Tcpdump output when I do a radtest to my running radiusd -X:
============================================================
09:31:40.232376 IP auth1.companyname.local.ldap >
auth1.companyname.local.40106: Flags [P.], seq 217:419, ack 203, win
342, options [nop,nop,TS val 1722796161 ecr 1722796160], length 202
E....t at .@...
. at .
. at ......:...N#T...V.......
f...f...0:...d5.1uid=klutest,cn=users,cn=compat,dc=companyname,dc=local0.0~...dy.3uid=klutest,cn=users,cn=accounts,dc=companyname,dc=local0B0 at ..userPassword10..{SSHA}NNYM5G7*************************YzNEdkA==0....e.
......
============================================================

Settings:
============================================================
  update {
   control:Password-With-Header  += 'userPassword'
#   control:NT-Password   := 'ntPassword'
#   reply:Reply-Message   := 'radiusReplyMessage'
#   reply:Tunnel-Type   := 'radiusTunnelType'
#   reply:Tunnel-Medium-Type  := 'radiusTunnelMediumType'
#   reply:Tunnel-Private-Group-ID := 'radiusTunnelPrivategroupId'
          }
============================================================

I noticed that ldapsearch is giving back the userPassword attribute
after two (!) colons instead of one. Maybe this is a hint? I searched
and this would mean that it is a base64 encoded value. I hope
freeradius picks this up?

If you (or anyone else) can tell me what settings I need to pick this
up, that would be great. The log output is below.
Thanks,
/kl

Log output when searching for an existing user:
============================================================
(1) suffix : No '@' in User-Name = "klutest", 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 (4)
(1) ldap :      expand: "(uid=%{%{Stripped-User-Name}:-%{User-Name}})"
-> '(uid=klutest)'
(1) ldap :      expand: "dc=companyname,dc=local" -> 'dc=companyname,dc=local'
(1) ldap : Performing search in 'dc=companyname,dc=local' with filter
'(uid=klutest)'
(1) ldap : Waiting for search result...
(1) ldap : User object found at DN
"uid=klutest,cn=users,cn=compat,dc=companyname,dc=local"
(1) ldap : Processing user attributes
(1) WARNING: ldap : No "reference" password added. Ensure the admin
user has permission to read the password attribute
(1) WARNING: ldap : PAP authentication will *NOT* work with Active
Directory (if that is what you were trying to configure)
rlm_ldap (ldap): Released connection (4)
rlm_ldap (ldap): Closing connection (1): Too many free connections (4 > 3)
rlm_ldap (ldap): Closing connection (3): Hit idle_timeout, was idle
for 109 seconds
rlm_ldap (ldap): Closing connection (2): Hit idle_timeout, was idle
for 109 seconds
rlm_ldap (ldap): You probably need to lower "min"
(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 to authenticate the user.
(1) Using Post-Auth-Type Reject
(1) # Executing group from file /etc/raddb/sites-enabled/default
(1)  Post-Auth-Type REJECT {
(1) attr_filter.access_reject :         expand: "%{User-Name}" -> 'klutest'
(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)    } # else else = 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 146 from 127.0.0.1 port 1812 to 127.0.0.1 port 48291
Waking up in 4.9 seconds.
(1) Cleaning up request packet ID 146 with timestamp +108
Ready to process requests.
============================================================

On Mon, Apr 13, 2015 at 3:59 PM, Arran Cudbard-Bell
<a.cudbardb at freeradius.org> wrote:
>
>> "uid=user,cn=users,cn=compat,dc=companyname,dc=local"
>> (0) ldap : Processing user attributes
>> (0) WARNING: ldap : No "reference" password added. Ensure the admin
>> user has permission to read the password attribute
>> (0) WARNING: ldap : PAP authentication will *NOT* work with Active
>> Directory (if that is what you were trying to configure)
>> rlm_ldap (ldap): Released connection (4)
>> rlm_ldap (ldap): Closing connection (0): Too many free connections (5 > 3)
>> (0)   [ldap] = ok
>> (0)   [expiration] = noop
>> (0)   [logintime] = noop
>> (0) WARNING: pap : No "known good" password found for the user.  Not
>> setting Auth-Type.
>> (0) WARNING: pap : Authentication will fail unless a "known good"
>> password is available.
>> (0)   [pap] = noop
>> (0)  } #  authorize = ok
>> (0) ERROR: No Auth-Type found: rejecting the user via Post-Auth-Type = Reject
>> ===============================================================
>>
>> Can FreeRadius handle this type of userPassword (since it seems to be hashed)?
>
> Yes, though you should map it to control:Password-With-Header, and run the pap module
> after the ldap module.
>
> At this point it's probably time to break out wireshark and look at the requests/responses
> you'll probably find that the LDAP server still isn't sending back a value for that
> attribute.
>
> Arran Cudbard-Bell <a.cudbardb at 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