Ldap binding with different attribute
Hi everbody,
I have a freeradius+openldap working well, but I'd like to make some changes.
Below are the ldap module configuration:
server = "ldap.mycompany.br"
identity = "cn=Admin,dc=univates,dc=br"
password = xx
basedn = "dc=mycompany,dc=br"
filter = "(uid=%{Stripped-User-Name:-%{User-Name}})"
dictionary_mapping = ${raddbdir}/ldap_acad.attrmap
ldap_connections_number = 5
timeout = 4
timelimit = 3
net_timeout = 1
The users auth w/ a bind using the normal attrs (uid and password), but I think
it'd better if users ALSO could use another attrs like 'studentCode' to auth,
instead of only uid/password.
Anyone know how to do that?
Cheers!
--
Leonardo Fell
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: LDAP Binding
On 02/10/2012 09:09 PM, NdK wrote: Can't create "users" in AD. Just machine accounts. Maybe it's possible to use the (or "a dedicated") *machine* account credentials? rlm_ldap just needs a bind DN. Any ldap DN with permissions to bind to the directory and execute the searches you need will suffice. If you say what you're trying to accomplish rather than how, it might be a bit clearer. Trying to avoid a script (1st exec of "bash") that does a "net ads search" (2nd exec), filters output with "sed" (it's been not too hard to write a script that does "grep", too -- 3rd exec). I need to determine if/what to return in 'access-accept' when an user authenticates to a switch. You've really got several choices: 1. Use an "exec" module, ideally in post-auth so it's only run once. Whether it's written in shell, perl, C or something else is your choice. 2. Bulk-query the data from LDAP, cache it into a local SQL / text file, query that with rlm_sql / rlm_passwd. For optional extra points, use the incremental LDAP search facility to "tail" changes to LDAP. 3. Query in real-time using rlm_ldap. As said, you can't use kerberos for this, you'll need a bind DN. 4. Something else. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: LDAP Binding
If you are looking to assign users network permissions may I suggest you look into the open source enterprise NAC called PacketFence, we are using it with great success. No use reinventing the wheel, especially when you can get a really tricked out wheel for free : ) Jake Sallee Godfather of Bandwidth Network Engineer University of Mary Hardin-Baylor 900 College St. Belton, Texas 76513 Fone: 254-295-4658 Phax: 254-295-4221 From: freeradius-users-bounces+jake.sallee=umhb@lists.freeradius.org [freeradius-users-bounces+jake.sallee=umhb@lists.freeradius.org] on behalf of Alan DeKok [al...@deployingradius.com] Sent: Friday, February 10, 2012 3:37 PM To: FreeRadius users mailing list Subject: Re: LDAP Binding NdK wrote: > Can't create "users" in AD. Just machine accounts. That's a local policy which can be changed. AD is perfectly capable of creating read-only administrator accounts. It's what everyone else does. > Maybe it's possible > to use the (or "a dedicated") *machine* account credentials? No. > Reading FR docs it seems it's something to avoid whenever possible. > Since there's an internal ldap module, I thought it could be possible to > use it. Yes. > I need to determine if/what to return in 'access-accept' when an user > authenticates to a switch. See the switch documentation for what to return in an Access-Accept. Every switch vendor has their own idea of what is "normal". > - students (determined by *domain* membership) receive a VLAN membership > - administrators (determined by *domain* and *group* membership) receive > *no* VLAN memberships (so they can access all the VLANS configured for > that switch port, as said on the wiki for HPs) > - "regular" users receive VLAN membership for a different VLAN than > students (preventing 'em to tamper with administration VLAN) That should all be straightforward. Write a shell script which implements those rules. Test it. Port the same rules to the internal FreeRADIUS LDAP module && unlang. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: LDAP Binding
NdK wrote: > Can't create "users" in AD. Just machine accounts. That's a local policy which can be changed. AD is perfectly capable of creating read-only administrator accounts. It's what everyone else does. > Maybe it's possible > to use the (or "a dedicated") *machine* account credentials? No. > Reading FR docs it seems it's something to avoid whenever possible. > Since there's an internal ldap module, I thought it could be possible to > use it. Yes. > I need to determine if/what to return in 'access-accept' when an user > authenticates to a switch. See the switch documentation for what to return in an Access-Accept. Every switch vendor has their own idea of what is "normal". > - students (determined by *domain* membership) receive a VLAN membership > - administrators (determined by *domain* and *group* membership) receive > *no* VLAN memberships (so they can access all the VLANS configured for > that switch port, as said on the wiki for HPs) > - "regular" users receive VLAN membership for a different VLAN than > students (preventing 'em to tamper with administration VLAN) That should all be straightforward. Write a shell script which implements those rules. Test it. Port the same rules to the internal FreeRADIUS LDAP module && unlang. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: LDAP Binding
Il 10/02/2012 16:21, Phil Mayers ha scritto: >> Is it possible to bind to AD's LDAP using the Kerberos ticket obtained >> at join time? > This question does not make sense. Joining a domain doesn't "obtain a > kerberos ticket". It creates a machine account principal, and a shared > secret (password) that can *in future* be used to obtain kerberos tickets. Yep. Sorry. Tried to "condense" too much :( > First, you can do that now. Just create a service account in AD for > searching LDAP, and set the bind DN. Can't create "users" in AD. Just machine accounts. Maybe it's possible to use the (or "a dedicated") *machine* account credentials? > Secondly, checking group membership over LDAP in AD is not as simple as > you might think. Nested groups and primary group ID are the two main > problems. I know: about 5-6 years ago I wrote a lot of PHP code that did exactly that. A nightmare. But doable. At least in PHP. > Thirdly, why do you assume that spawning a process is undesirable? Have > you tested it to see which is slower? Reading FR docs it seems it's something to avoid whenever possible. Since there's an internal ldap module, I thought it could be possible to use it. > If you say what you're trying to accomplish rather than how, it might be > a bit clearer. Trying to avoid a script (1st exec of "bash") that does a "net ads search" (2nd exec), filters output with "sed" (it's been not too hard to write a script that does "grep", too -- 3rd exec). I need to determine if/what to return in 'access-accept' when an user authenticates to a switch. - students (determined by *domain* membership) receive a VLAN membership - administrators (determined by *domain* and *group* membership) receive *no* VLAN memberships (so they can access all the VLANS configured for that switch port, as said on the wiki for HPs) - "regular" users receive VLAN membership for a different VLAN than students (preventing 'em to tamper with administration VLAN) BYtE, Diego. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: LDAP Binding
On 10/02/12 14:38, NdK wrote: Hello all. Is it possible to bind to AD's LDAP using the Kerberos ticket obtained at join time? This question does not make sense. Joining a domain doesn't "obtain a kerberos ticket". It creates a machine account principal, and a shared secret (password) that can *in future* be used to obtain kerberos tickets. That would allow to search for group membership without spawning more processes... Three points: First, you can do that now. Just create a service account in AD for searching LDAP, and set the bind DN. Secondly, checking group membership over LDAP in AD is not as simple as you might think. Nested groups and primary group ID are the two main problems. Thirdly, why do you assume that spawning a process is undesirable? Have you tested it to see which is slower? If you say what you're trying to accomplish rather than how, it might be a bit clearer. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: LDAP Binding
NdK wrote: > Is it possible to bind to AD's LDAP using the Kerberos ticket obtained > at join time? No. The LDAP API doesn't support that. > That would allow to search for group membership without spawning more > processes... Huh? You can configure AD as an LDAP server, and do group membership checks. All you need is a read-only administrator account. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
LDAP Binding
Hello all. Is it possible to bind to AD's LDAP using the Kerberos ticket obtained at join time? That would allow to search for group membership without spawning more processes... Tks, Diego. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
