Porting ldap module configuration from 2.2.9 to 3.0.15

[Olivier]

Thank you Fajar for the time you spend helping me.

Olivier

"Fajar A. Nugraha" <list at fajar.net> writes:

> On Wed, Sep 20, 2017 at 7:40 PM, Fajar A. Nugraha <list at fajar.net> wrote:
>
>> On Wed, Sep 20, 2017 at 3:03 PM, Olivier <Olivier.Nicole at cs.ait.ac.th>
>> wrote:
>>
>>>
>>>
>> Could it be something linked to user-Password vs. Cleartext-Password, as
>>> mentioned in raddb/README.rst:
>>>
>>>    From version 3.0 onwards the server no longer supports authenticating
>>>    against a cleartext password in the 'User-Password' attribute. Any
>>>    occurences of this (for instance, in the users file) should now be
>>>    changed to 'Cleartext-Password' instead.
>>>
>>>
> To be clear: this is related to what you have in whatever database that
> stores your user passwords. Can be users file, db, LDAP, etc. The attribute
> name stored in that database (for unencrypted password) should be
> 'Cleartext-Password', not 'User-Password'.
>
> The Cleartext-Password attribute is not what the NAS (i.e. radtest, wifi
> access point, etc) sends.
>
>
>>
>>> I see that radtest sends both User-Password and Cleartext-Password:
>>>
>>> Sent Access-Request Id 17 from 0.0.0.0:24803 to 192.41.170.3:1812 length
>>> 72
>>>         User-Name = "on"
>>>         User-Password = "**** password redacted"
>>>         NAS-IP-Address = 192.41.170.6
>>>         NAS-Port = 0
>>>         Message-Authenticator = 0x00
>>>         Cleartext-Password = "**** password redacted"
>>>
>>>
> I believe it prints 'Cleartext-Password' for debug purposes, to show 'what
> password you put in the command line'. In the case of pap (default in
> radtest), User-Password attribute (the one that actually gets sent) will
> have the same value. However if you use 'radtest -t eap-md5', there will be
> no attribute sent that contains the clear-text password (but radtest would
> still print 'Cleartext-Password' and fill it with your input).
>
> You can examine the actual attributes sent using tcpdump (or other similar
> tools, like wireshark). An example from mine:
>
> # tcpdump -i lo port 1812 -vv
> tcpdump: listening on lo, link-type EN10MB (Ethernet), capture size 262144
> bytes
> 19:46:13.702277 IP (tos 0x0, ttl 64, id 24410, offset 0, flags [none],
> proto UDP (17), length 103)
>     localhost.44576 > localhost.radius: [bad udp cksum 0xfe66 -> 0x8fcb!]
> RADIUS, length: 75
>         Access-Request (1), id: 0x4c, Authenticator:
> 784e48bc200a17e20a5d8618c5510c27
>           User-Name Attribute (1), length: 7, Value: admin
>             0x0000:  6164 6d69 6e
>           User-Password Attribute (2), length: 18, Value:
>             0x0000:  *** masked ***
>           NAS-IP-Address Attribute (4), length: 6, Value: build
>             0x0000:  7f00 0101
>           NAS-Port Attribute (5), length: 6, Value: 0
>             0x0000:  0000 0000
>           Message-Authenticator Attribute (80), length: 18, Value:
> ....2....&V..4.S
>             0x0000:  1ffc 96da 320c d71d c926 5682 8834 0f53
>
> It sends 5 attributes, the same one as what freeradius debug mode prints.
> No 'Cleartext-Password' attribute sent.

--