Freeipa and Freeradius integration

[KL Forwarder]

Hi Arran,

On Wed, Apr 22, 2015 at 11:35 AM, Arran Cudbard-Bell
<a.cudbardb at 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 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.
>> ......
>
> 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