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