Hi,

default behaviour. so a configured LDAP in modules/ldap will always be queried first? or does it depend on the placement of "DEFAULT Ldap-Group == " in the users file?

if you look at the config - by default, the 'default virtual server in sites-enabled, the server goes through the authorize section first, if ldap is enabled in there, then ldap may be used in the authenticate section - if its enabled - read the configuration file ALL the info you need is actually written in there (unless you have removed it, of the package maintainer has)

It can also be the firewall here which I have to figure out. "radtest USERNAME PASSWORD localhost 0 testing123" still results in an access-reject

<shrug> as already said, you are not providing information, the standard response of 'whats the output of radiusd -X' is for the purpose of getting tha info...the server will be showing you exactly what it does and why things are failing. run in full debug...until you get things working. alan

On Mar 8, 2017, at 2:28 AM, Konstantin Knaab-Hinrichs via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:

Here's the "freeradius -X" (somehow it isn't radiusd -X on my side)

Debian and Redhat rename the binary. This is documented in the FAQ. And the reason we tell you to run it in debug mode is so that you will READ THE OUTPUT. Specifically:

...

[ldap] Bind was successful [ldap] performing search in dc=$DOMAIN,dc=local, with filter (uid=$USER) WARNING: Please set 'chase_referrals=yes' and 'rebind=yes' WARNING: See the ldap module configuration for details

If only the server produced a USEFUL MESSAGE WHICH TOLD YOU HOW TO FIX THE PROBLEM.

As I read the log part

...

[ldap] ldap_search() failed: Operations error [ldap] search failed [ldap] ldap_release_conn: Release Id: 0 ++[ldap] = fail +} # group authorize = fail Invalid user: [$USER] (from client localhost port 0)

You read that, and ignored the HUGE WARNING MESSAGE. The message that told you how to fix the problem. Alan DeKok.

On Mar 8, 2017, at 10:38 AM, Konstantin Knaab-Hinrichs <paradonym@googlemail.com> wrote:

To solve this I removed the comment from

chase_referrals = yes rebind = yes

in the tls section of /modules/ldap

Those entries aren't in the "tls" section of raddb/modules/ldap.

and restarted the service and freeradius -X.

Did you READ the output, to see if it's using the "chase_referrals" configuration? It will print out the LDAP module config, including all of the settings. If there's no "chase_referrals = yes" in the debug output, then you edited the wrong thing.

The warning messages hadn't changed. Everything described in the .conf files should now be the way it should. http://wiki.freeradius.org/modules/Rlm_ldap somehow describes something different than the installed .conf files.

Because you're using version 2, which is end of life. Version 3 is the officially supported version.

http://confluence.diamond.ac.uk/display/PAAUTH/Using+LDAP+as+authentication+... (the wiki links to this article) states that eap.conf (/freeradius/eap.conf in my case) that nothing has to be changed in eap.conf if you use Microsoft PEAP - which I think is the case for a microsoft domain controller.

That is written by someone else, and I wouldn't believe any third-party documentation. It might be correct, but third-party documentation is more often wrong.

After editing /sites-available/inner-tunnel (the mods-available alternative for debian I think) like the above diamond.ac.uk link states results in these messages when trying to debug-start freeradius

/etc/freeradius/sites-enabled/inner-tunnel[170]: ERROR: Unknown value ldap for attribute Auth-Type /etc/freeradius/sites-enabled/inner-tunnel[169]: Failed to parse "update" subsection. /etc/freeradius/sites-enabled/inner-tunnel[48]: Errors parsing authorize section.

The server you're running includes TONS of documentation in the configuration files. That documentation explains how the server works, and what each configuration item does. I suggest reading those, instead of random third-party web sites. The FreeRADIUS documentation has said for YEARS to not set Auth-Type. If that third-party page is telling you to set "Auth-Type = LDAP", it's wrong. I also suggest upgrading to version 3. It's much better.

LDAP connection seems to be possible ([ldap] Bind was successful) and ++[ldap] = fail states that the LDAP didn't reply to the specific question if $USER is in the database or specifically said it isn't in the db.

The debug output says what it's doing, and what happens. Read it. And, follow the documentation on my web site: http://deployingradius.com/ It has detailed instructions for getting PEAP to work, and getting the server to work with AD. The page has been up for over 10 years. It's correct. It will work for version 2 or version 3, if you pay attention to small differences between the versions. It WILL work. I just have no idea why people spend so much time (a) ignoring the debug output of the server, and (b) following crappy third-party documentation instead of official FreeRADIUS docs. It just makes no sense. Alan DeKok.

Hi,

different than the installed .conf files. http://confluence.diamond.ac.uk/display/PAAUTH/Using+LDAP+as+authentication+... <http://confluence.diamond.ac.uk/display/PAAUTH/Using+LDAP+as+authentication+source>

ANOTHER 3rd party web site. this a contual habit of yours?

wiki links to this article) states that eap.conf (/freeradius/eap.conf in my case) that nothing has to be changed in eap.conf if you use Microsoft PEAP - which I think is the case for a microsoft domain controller.

things have to be changed - things specific to youy - eg EAP type, the certificate you need to use , your CA etc etc

After editing /sites-available/inner-tunnel (the mods-available alternative for debian I think) like the above diamond.ac.uk link states results in these messages when trying to debug-start freeradius

mods-available is for modules that are available - , sites-available is for sites that are available. note AVAILABLE to ensur ethey are being used, you need to check the contents of sites-enabled and mods-enabled this is true for 3.0.x on ANY OS, its not specific to an OS

...

/etc/freeradius/sites-enabled/inner-tunnel[170]: ERROR: Unknown value ldap for attribute Auth-Type

correct. read he provided inline documentation in the config files. its all there. check you have ldap enabled (in mods-enabled) alan

On Mar 9, 2017, at 4:10 AM, Konstantin Knaab-Hinrichs <paradonym@googlemail.com> wrote:

just compiled and installed freeradius 3. make installed raddb into a subfolder. Can I move the folder to /etc/raddb without compatibility issues?

You need to install version 3 in a new directory, and then manually re-create the configuration. Again, this is documented in the v3 distribution. Read it.

According to wiki I guess there's no issue if freeradius 2 is installed but deactivated on the same machine - as the services were renamed to radiusd. I'll try to follow http://confluence.diamond.ac.uk/display/PAAUTH/Using+LDAP+as+authentication+... as a guideline

You've been told repeatedly to not do that. Why are you asking questions when you continually ignore the answers? Alan DeKok.

Just because there is a log missing an @ in the user string I tried the modern way "radtest $USER@$DOMAIN.local ..." rad_recv: Access-Request packet from host 127.0.0.1 port 54456, id=72,

...

length=102

User-Name = "$USER@$DOMAIN.local"

User-Password = "$PASS"

NAS-IP-Address = 127.0.1.1

NAS-Port = 0

Message-Authenticator = 0x571ceeee8066a0c6a5982deb5a6161b3

# Executing section authorize from file

...

/etc/freeradius/sites-enabled/default

+group authorize {

++[preprocess] = ok

++[chap] = noop

++[mschap] = noop

++[digest] = noop

[suffix] Looking up realm "$DOMAIN.local" for User-Name = "$USER@

...

$DOMAIN.local"

[suffix] No such realm "$DOMAIN.local"

++[suffix] = noop

[eap] No EAP-Message, not doing EAP

++[eap] = noop

[ldap] Entering ldap_groupcmp()

[files] expand: dc=$DOMAIN,dc=local -> dc=$DOMAIN,dc=local

[files] expand: %{Stripped-User-Name} ->

[files] ... expanding second conditional

[files] expand: %{User-Name} -> $USER@$DOMAIN.local

[files] expand: (uid=%{%{Stripped-User-Name}:-%{User-Name}}) ->

...

(uid=$USER@$DOMAIN.local)

[ldap] ldap_get_conn: Checking Id: 0

[ldap] ldap_get_conn: Got Id: 0

[ldap] attempting LDAP reconnection

[ldap] closing existing LDAP connection

[ldap] (re)connect to $DOMAINCONTROLLERIP:389, authentication 0

[ldap] bind as / to $DOMAINCONTROLLERIP:389

[ldap] waiting for bind result ...

[ldap] Bind was successful

[ldap] performing search in dc=$DOMAIN,dc=local, with filter (uid=$USER@

...

$DOMAIN.local)

WARNING: Please set 'chase_referrals=yes' and 'rebind=yes'

WARNING: See the ldap module configuration for details

[ldap] ldap_search() failed: Operations error

rlm_ldap::ldap_groupcmp: search failed

[ldap] ldap_release_conn: Release Id: 0

++[files] = noop

[ldap] performing user authorization for $USER@$DOMAIN.local

[ldap] expand: %{Stripped-User-Name} ->

[ldap] ... expanding second conditional

[ldap] expand: %{User-Name} -> $USER@$DOMAIN.local

[ldap] expand: (uid=%{%{Stripped-User-Name}:-%{User-Name}}) -> (uid=$USER@

...

$DOMAIN.local)

[ldap] expand: dc=$DOMAIN,dc=local -> dc=$DOMAIN,dc=local

[ldap] ldap_get_conn: Checking Id: 0

[ldap] ldap_get_conn: Got Id: 0

[ldap] attempting LDAP reconnection

[ldap] closing existing LDAP connection

[ldap] (re)connect to $DOMAINCONTROLLERIP:389, authentication 0

[ldap] bind as / to $DOMAINCONTROLLERIP:389

[ldap] waiting for bind result ...

[ldap] Bind was successful

[ldap] performing search in dc=$DOMAIN,dc=local, with filter (uid=$USER@

...

$DOMAIN.local)

WARNING: Please set 'chase_referrals=yes' and 'rebind=yes'

WARNING: See the ldap module configuration for details

[ldap] ldap_search() failed: Operations error

[ldap] search failed

[ldap] ldap_release_conn: Release Id: 0

++[ldap] = fail

+} # group authorize = fail

Invalid user: [$USER@$DOMAIN.local] (from client localhost port 0)

Using Post-Auth-Type REJECT

# Executing group from file /etc/freeradius/sites-enabled/default

+group REJECT {

[attr_filter.access_reject] expand: %{User-Name} -> $USER@

...

$DOMAIN.local

attr_filter: Matched entry DEFAULT at line 11

++[attr_filter.access_reject] = updated

+} # group REJECT = updated

Delaying reject of request 1 for 1 seconds

Going to the next request

Waking up in 0.9 seconds.

Sending delayed reject for request 1

Sending Access-Reject of id 72 to 127.0.0.1 port 54456

Waking up in 4.9 seconds.

Cleaning up request 1 ID 72 with timestamp +5685

Ready to process requests.

the reject message is coming much faster. I'm unsure if this is because of configuration issues or a reject of the ldap query.