Freeipa and Freeradius integration
All, I can use your help. I am trying to set up freeradius on my RHEL IDM/freeipa server. A mail [0] from the freeipa list indicated that this would be easy, but I think I am missing one step. So far, freeradius can find the user in ldap ("User object found at DN "uid=username,cn=users,cn=compat,dc=companyname,dc=local"). It just does not seem to be able to verify if the pass word is correct. What steps do I need to take? I am just trying to figure this out, I don't have a guide or anything. I have uploaded my radiusd.conf [ http://pastebin.com/GijucMps ], my mods-available/ldap [ http://pastebin.com/YJTi8srS ] and sites-available/ldap [ http://pastebin.com/MMGzU8Sj ]. All help is welcome. Is is probably something easy. This is the log I get: ============================================================ (0) # Executing section authorize from file /etc/raddb/sites-enabled/default (0) authorize { (0) filter_username filter_username { (0) ? if (User-Name != "%{tolower:%{User-Name}}") (0) expand: "%{tolower:%{User-Name}}" -> 'klu' (0) ? if (User-Name != "%{tolower:%{User-Name}}") -> FALSE (0) ? if (User-Name =~ / /) (0) ? if (User-Name =~ / /) -> FALSE (0) ? if (User-Name =~ /@.*@/ ) (0) ? if (User-Name =~ /@.*@/ ) -> FALSE (0) ? if (User-Name =~ /\\.\\./ ) (0) ? if (User-Name =~ /\\.\\./ ) -> FALSE (0) ? if ((User-Name =~ /@/) && (User-Name !~ /@(.+)\\.(.+)$/)) (0) ? if ((User-Name =~ /@/) && (User-Name !~ /@(.+)\\.(.+)$/)) -> FALSE (0) ? if (User-Name =~ /\\.$/) (0) ? if (User-Name =~ /\\.$/) -> FALSE (0) ? if (User-Name =~ /@\\./) (0) ? if (User-Name =~ /@\\./) -> FALSE (0) } # filter_username filter_username = notfound (0) [preprocess] = ok (0) [chap] = noop (0) [mschap] = noop (0) [digest] = noop (0) suffix : No '@' in User-Name = "klu", looking up realm NULL (0) suffix : No such realm "NULL" (0) [suffix] = noop (0) eap : No EAP-Message, not doing EAP (0) [eap] = noop (0) [files] = noop rlm_ldap (ldap): Reserved connection (4) (0) ldap : expand: "(uid=%{%{Stripped-User-Name}:-%{User-Name}})" -> '(uid=klu)' (0) ldap : expand: "dc=kahuna,dc=local" -> 'dc=kahuna,dc=local' (0) ldap : Performing search in 'dc=kahuna,dc=local' with filter '(uid=klu)' (0) ldap : Waiting for search result... (0) ldap : User object found at DN "uid=klu,cn=users,cn=compat,dc=kahuna,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) (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 (0) Failed to authenticate the user. (0) Using Post-Auth-Type Reject (0) # Executing group from file /etc/raddb/sites-enabled/default (0) Post-Auth-Type REJECT { (0) attr_filter.access_reject : expand: "%{User-Name}" -> 'klu' (0) attr_filter.access_reject : Matched entry DEFAULT at line 11 (0) [attr_filter.access_reject] = updated (0) eap : Request didn't contain an EAP-Message, not inserting EAP-Failure (0) [eap] = noop (0) remove_reply_message_if_eap remove_reply_message_if_eap { (0) ? if (reply:EAP-Message && reply:Reply-Message) (0) ? if (reply:EAP-Message && reply:Reply-Message) -> FALSE (0) else else { (0) [noop] = noop (0) } # else else = noop (0) } # remove_reply_message_if_eap remove_reply_message_if_eap = noop (0) } # Post-Auth-Type REJECT = updated (0) Finished request 0. ============================================================ [0] https://www.redhat.com/archives/freeipa-users/2008-October/msg00036.html Thanks!
(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)
It's almost like this had happened before :) Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Fri, Apr 10, 2015 at 3:27 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
(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)
It's almost like this had happened before :)
I saw that indeed ;). I now added the admin user in the ldap config file now. It was complaining before (wrong dn), but it is starting now. I assume that the user I set is correct then ("identity = "uid=admin,cn=users,cn=accounts,dc=companyname,dc=local"), with the admin password. Problem is I still get: (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) How can I test if the password is correct? And are there references I can use (maybe a good general "Freeradius-ldap" guide?). Thanks so far, /kl
On 10 Apr 2015, at 10:08, KL Forwarder <kl.forwarder@gmail.com> wrote:
On Fri, Apr 10, 2015 at 3:27 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
(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)
It's almost like this had happened before :)
I saw that indeed ;).
I now added the admin user in the ldap config file now. It was complaining before (wrong dn), but it is starting now. I assume that the user I set is correct then ("identity = "uid=admin,cn=users,cn=accounts,dc=companyname,dc=local"), with the admin password.
Looks reasonable.
Problem is I still get:
(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)
How can I test if the password is correct? And are there references I can use (maybe a good general "Freeradius-ldap" guide?). Thanks so
You need to check if ldapsearch returns the userPassword attribute when bound with the credentials you configured for FR. The server is warning you that you had a mapping between an LDAP attribute, and a RADIUS attribute it knows is used to store the users password, but that the mapping was skipped because the LDAP server didn't return a value for that attribute. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Fri, Apr 10, 2015 at 6:15 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
Problem is I still get:
(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)
How can I test if the password is correct? And are there references I can use (maybe a good general "Freeradius-ldap" guide?). Thanks so
You need to check if ldapsearch returns the userPassword attribute when bound with the credentials you configured for FR.
The server is warning you that you had a mapping between an LDAP attribute, and a RADIUS attribute it knows is used to store the users password, but that the mapping was skipped because the LDAP server didn't return a value for that attribute.
Thanks so far, this helps. I tested and it indeed turned out I did not receive the userPassword attribute. I do get something like it back using `identity = "cn=Directory Manager"`, so I am using that now. Doing a ldapsearch gives me: [user@auth1 ~]$ ldapsearch -x -v -W -D 'cn=Directory Manager' uid=user | grep userP ldap_initialize( <DEFAULT> ) Enter LDAP Password: filter: uid=user requesting: All userApplication attributes userPassword:: e1NTS***************************************************************UE9PQ= userPassword is base64 encoded. Doing a base64 -d gives me "{SSHA}a3By*******************8kwtali5aA". Radius output is: =============================================================== (0) ldap : expand: "dc=companyname,dc=local" -> 'dc=companyname,dc=local' (0) ldap : Performing search in 'dc=companyname,dc=local' with filter '(uid=user)' (0) ldap : Waiting for search result... (0) ldap : User object found at DN "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)? Thanks, /kl
"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@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
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@.@... .@. .@......:...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@..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@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@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 22 Apr 2015, at 09:01, KL Forwarder <kl.forwarder@gmail.com> wrote:
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= ============================================================
That doesn't mean it looks like that on the wire, or is what FreeRADIUS receives, it's just how ldapsearch has chosen to display the value.
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@.@... .@. .@......:...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@..userPassword10..{SSHA}NNYM5G7*************************YzNEdkA==0....e. ......
That's not very helpful. We'd need the hex output at least (each of those dots is an unprintable char), or preferably a pcap file (you can send that to me directly if you prefer).
============================================================
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' } ============================================================
Those are correct.
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.
It's displaying a base64 encoded value, it's likely not stored that way in the directory, and as you can see, on the wire, it's the raw value.
I hope freeradius picks this up?
PAP can convert from base64 values, but it won't be receiving one in this case.
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.
Could you remind us what directory server you're using again? -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Hi Arran, On Wed, Apr 22, 2015 at 11:35 AM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
Ldapsearch output (|grep userPass): ============================================================ userPassword:: e1NTSEF9Tk5***************************************ka0E9PQ= ============================================================
That doesn't mean it looks like that on the wire, or is what FreeRADIUS receives, it's just how ldapsearch has chosen to display the value.
Ah yes I see.
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@.@... .@. .@......:...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@..userPassword10..{SSHA}NNYM5G7*************************YzNEdkA==0....e. ......
That's not very helpful. We'd need the hex output at least (each of those dots is an unprintable char), or preferably a pcap file (you can send that to me directly if you prefer).
I created a pcap file and it is attached. I think it caught the good packet.
============================================================
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' } ============================================================
Those are correct.
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.
It's displaying a base64 encoded value, it's likely not stored that way in the directory, and as you can see, on the wire, it's the raw value.
I hope freeradius picks this up?
PAP can convert from base64 values, but it won't be receiving one in this case.
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.
Could you remind us what directory server you're using again?
Red Hat Identity Management server, which is about the same as freeipa [ http://www.freeipa.org/page/Main_Page ]. I intend to write a short guide once this works, I think it will be necessary for more people. Kind regards, Karlo
That's not very helpful. We'd need the hex output at least (each of those dots is an unprintable char), or preferably a pcap file (you can send that to me directly if you prefer).
I created a pcap file and it is attached. I think it caught the good packet.
Can you resend. I've allowed 'application/octet-stream' as an attachment, so the listserv should preserve it. Still building the list of useful content types. On the plus side, no horrifically formatted HTML email, and there's been a noticeable drop in garish signature images :) -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On 22 Apr 2015, at 12:14, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
That's not very helpful. We'd need the hex output at least (each of those dots is an unprintable char), or preferably a pcap file (you can send that to me directly if you prefer).
I created a pcap file and it is attached. I think it caught the good packet.
Can you resend. I've allowed 'application/octet-stream' as an attachment, so the listserv should preserve it. Still building the list of useful content types.
On the plus side, no horrifically formatted HTML email, and there's been a noticeable drop in garish signature images :)
Ok, after reviewing the capture (sent off list)... The search is returning multiple entries for the same object, the first of which holds no attributes. FreeRADIUS only processes the first result, which is why no attributes are being added. This is sane behaviour on the part of FreeRADIUS. RFC4511 doesn't mention a situation where multiple searchResults can be returned for the same object, but neither does it expressly forbid it. Your capture missed the search request, so I can't tell if that was because some unusual search control got added. Can you send a capture with the search request too? Preferably one from ldapsearch and one from FreeRADIUS so we can see the differences. Also complete output from ldapsearch would be useful, with maximum verbosity. I imagine it'll show two search results returned, one with no attributes, and one with attributes. If it only displays one, i'll check through the OpenLDAP code and figure out why. Maybe they know something we don't... What's odd is this would have been an issue with v2.x.x and v1.x.x, but it's only been reported now... So either this is a new bug/feature in RedHat's LDAP server, or your LDAP configuration is broken. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Hi, On Wed, Apr 22, 2015 at 2:37 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
Can you resend. I've allowed 'application/octet-stream' as an attachment, so the listserv should preserve it. Still building the list of useful content types.
On the plus side, no horrifically formatted HTML email, and there's been a noticeable drop in garish signature images :)
:)
Ok, after reviewing the capture (sent off list)...
The search is returning multiple entries for the same object, the first of which holds no attributes. FreeRADIUS only processes the first result, which is why no attributes are being added. This is sane behaviour on the part of FreeRADIUS.
RFC4511 doesn't mention a situation where multiple searchResults can be returned for the same object, but neither does it expressly forbid it.
Your capture missed the search request, so I can't tell if that was because some unusual search control got added.
Can you send a capture with the search request too? Preferably one from ldapsearch and one from FreeRADIUS so we can see the differences. Also complete output from ldapsearch would be useful, with maximum verbosity.
I imagine it'll show two search results returned, one with no attributes, and one with attributes. If it only displays one, i'll check through the OpenLDAP code and figure out why. Maybe they know something we don't...
I *think* it shows two. But the output might mean more to you.
What's odd is this would have been an issue with v2.x.x and v1.x.x, but it's only been reported now... So either this is a new bug/feature in RedHat's LDAP server, or your LDAP configuration is broken.
I have not seen a lot of people trying it, that might be the reason. What I have done, and will send you off-list (privacy) is: 1) start a tcpdump (tcpdump -A -i any -w dump_all_port_389_and_1812.pcap port 389 or port 1812) 2) start radiusd (radiusd -X 2>&1 | tee radiusd.out) 3) do a radtest (~16:33:28) (radtest klutest password 127.0.0.1 1812 41P***********qcfu | tee radtest.out) 4) do a ldapsearch (ldapsearch -x -v -W -D 'cn=Directory Manager' uid=klutest) 5) stop the tcpdump I will send you the files. Thanks again. /kl
participants (2)
-
Arran Cudbard-Bell -
KL Forwarder