The LDAP server we have set up is used to authenticate users based on their username and password. If I were to query from the (Linux) command line using ldapsearch, the query would appear as follows: ldapsearch -x -h ldap.domain.com -b ou=ldap,o=domain.com -D uid=XXX,ou=it,o= domain.com -w 'YYY' Where XXX is a person's username and YYY is their password. That means a person can only query their own information and not anyone elses (unless, of course, they have someone else's username and password).
From what I can see, it doesn't appear as though the %{User-Name} variable can be used within the "identity" setting in freeRADIUS 1.0.1. If that's correct, does it mean freeRadius won't be able to be used for this particular set up? If I hardcode a test username and password in the configuration as follows:
server = "ldap.domain.com" identity = "uid=XXX,ou=it,o=domain.com" password = 'YYY' basedn = "ou=ldap,o=domain.com" it binds correctly. However, for our particular setup, both the username and password's used to bind to the server need to be variable at run time.
Derrick Woo wrote:
The LDAP server we have set up is used to authenticate users based on their username and password. If I were to query from the (Linux) command line using ldapsearch, the query would appear as follows:
ldapsearch -x -h ldap.domain.com -b ou=ldap,o=domain.com -D uid=XXX,ou=it,o= domain.com -w 'YYY'
Where XXX is a person's username and YYY is their password. That means a person can only query their own information and not anyone elses (unless, of course, they have someone else's username and password).
From what I can see, it doesn't appear as though the %{User-Name} variable can be used within the "identity" setting in freeRADIUS 1.0.1. If that's correct, does it mean freeRadius won't be able to be used for this particular set up? If I hardcode a test username and password in the configuration as follows:
server = "ldap.domain.com" identity = "uid=XXX,ou=it,o=domain.com" password = 'YYY' basedn = "ou=ldap,o=domain.com"
it binds correctly. However, for our particular setup, both the username and password's used to bind to the server need to be variable at run time.
"identity" and "password" are the DN and password of a user representing the *server*, e.g. identity = "uid=freeRadiusServiceAccount,o=domain.com" ...the LDAP module first binds as identity, searches using the given "basedn" and "filter", then re-binds as the user, or returns access denied / not found. If you don't have a service account and allow anonymous binds (eek) just comment identity and password out.
------------------------------------------------------------------------
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hello Phil, Thanks for your response. However as I had mentioned in my post, this particular LDAP server uses a person's username and password for binding. There is no service account and anonymous binds are not allowed. Commenting out identity and password did not work. Am I out of luck here? On 12/13/05, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
Derrick Woo wrote:
The LDAP server we have set up is used to authenticate users based on their username and password. If I were to query from the (Linux) command line using ldapsearch, the query would appear as follows:
ldapsearch -x -h ldap.domain.com -b ou=ldap,o=domain.com -D uid=XXX,ou=it,o= domain.com -w 'YYY'
Where XXX is a person's username and YYY is their password. That means a person can only query their own information and not anyone elses (unless, of course, they have someone else's username and password).
From what I can see, it doesn't appear as though the %{User-Name} variable can be used within the "identity" setting in freeRADIUS 1.0.1. If that's correct, does it mean freeRadius won't be able to be used for this particular set up? If I hardcode a test username and password in the configuration as follows:
server = "ldap.domain.com" identity = "uid=XXX,ou=it,o=domain.com" password = 'YYY' basedn = "ou=ldap,o=domain.com"
it binds correctly. However, for our particular setup, both the username and password's used to bind to the server need to be variable at run time.
"identity" and "password" are the DN and password of a user representing the *server*, e.g.
identity = "uid=freeRadiusServiceAccount,o=domain.com"
...the LDAP module first binds as identity, searches using the given "basedn" and "filter", then re-binds as the user, or returns access denied / not found.
If you don't have a service account and allow anonymous binds (eek) just comment identity and password out.
------------------------------------------------------------------------
- List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Derrick Woo wrote:
Hello Phil,
Thanks for your response. However as I had mentioned in my post, this particular LDAP server uses a person's username and password for binding. There is no service account and anonymous binds are not allowed. Commenting out identity and password did not work.
Am I out of luck here?
Ah, you don't want to search *at all*. Remove "ldap" from the authorize section, leave it in the "authenticate" section, and set: DEFAULT Ldap-UserDN := `uid=%{User-Name},ou=people,dc=company,dc=com` ...in the users file. (Adding the Ldap-UserDN is basically what the ldap module *does* in the authorize section). This is documented in doc/rlm_ldap
Hello Phil, I've removed "ldap" from the authorize section now, but now it's not even connecting to the ldap server. Am I overlooking something? Thank you for your help. It's greatly appreciated. Derrick On 12/13/05, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
Derrick Woo wrote:
Hello Phil,
Thanks for your response. However as I had mentioned in my post, this particular LDAP server uses a person's username and password for binding. There is no service account and anonymous binds are not allowed. Commenting out identity and password did not work.
Am I out of luck here?
Ah, you don't want to search *at all*. Remove "ldap" from the authorize section, leave it in the "authenticate" section, and set:
DEFAULT Ldap-UserDN := `uid=%{User-Name},ou=people,dc=company,dc=com`
...in the users file. (Adding the Ldap-UserDN is basically what the ldap module *does* in the authorize section). This is documented in doc/rlm_ldap - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Derrick Woo wrote:
Hello Phil,
I've removed "ldap" from the authorize section now, but now it's not even connecting to the ldap server. Am I overlooking something?
Weeellll... I must be honest, I've never actually used it myself (ducks :o) but that's certainly what the source and docs imply. (goes off to try) Ah, the users file *actually* needs to be: DEFAULT Auth-Type := LDAP, Ldap-UserDN := `uid=%{User-Name},RESTOFDN` ...because the authenticate section has ldap as a conditional module: authenticate { Auth-Type LDAP { ldap } } With the final above fixe, this definitely works for me. However, you should be aware of the implications of setting (forcing) Auth-Type in the users file - by forcing it to LDAP unconditionally you will prevent e.g. mschap, eap, etc. working at a later date (this is why it's generally not recommended, but for specific and limited circumstances where you're sure this is what you want, I guess it's ok) You could put the "files" module last in the authorize section, and use: DEFAULT Auth-Type = LDAP, Ldap-... ...which will only set the Auth-Type if it's not already set - then if e.g. mschap or eap match first, ldap won't attempt to sieze the request. [Perhaps someone else could chip in with info about the implications of putting the "ldap" module as a non-conditional in "authenticate" - I was under the impression that all the modules in authenticate should be conditional because only one was ever called, but e.g. digest, pam, unix, eap don't seem to be?]
participants (2)
-
Derrick Woo -
Phil Mayers