363821 - LDAP authentication: restrict access to LDAP group

Status: NEW

(Bugzilla :: User Accounts, enhancement)

Description

[Uli]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7
Build Identifier: Bugzilla  Version 2.22.1  

Given a company wide LDAP installation it is nice to be able to restrict access to bugzilla to an LDAP group

Reproducible: Always

Comment 1

[Uli]

Attachment: introduces LDAPgroup into LDAP configuration and checks it on login

The patch adds a parameter LDAPgroup and checks if a user belongs to that group on login.

Comment 2

[Frédéric Buclin]

Comment on attachment 248638 [details] [diff] [review]
introduces LDAPgroup into LDAP configuration and checks it on login

>+++ Bugzilla/Config/LDAP.pm	2006-12-13 15:27:28.000000000 +0100

>+  {
>+   name => 'LDAPgroup',
>+   type => 't',
>+   default => ''
>+  });

You have to add a param description to admin/params/ldap.html.tmpl.



>+++ Bugzilla/Auth/Verify/LDAP.pm	2006-12-14 13:34:44.000000000 +0100

>+    if (Param("LDAPgroup")) {

Param() no longer exists in Bugzilla 3.0.

Comment 3

[Max Kanat-Alexander]

This can be accomplished already with the LDAPFilter parameter.

Comment 4

[Uli]

(In reply to comment #3)
> This can be accomplished already with the LDAPFilter parameter.
> 

I don't think so.
If you disagree I'd very much like to see an example.

If you just pull the users record, you don't get any group information. Therefore a filter won't be of much help.
In a second query you can pull the group entry and check if the user is a member. That's what the patch does
Hereby I am referring to the usual LDAP layout where membership is stored in the group record and not in the users records.

Comment 5

[Frédéric Buclin]

Better to CC Max if you want him to reply. :)

Comment 6

[Max Kanat-Alexander]

Well, I'll at least re-open it.

I think there are a few issues here, the most important being that different LDAP servers work differently, and different people have different schemas.

I don't understand why the LDAPfilter in Bugzilla 3.0 doesn't work for you--look at the new code, not the 2.22 code. Authentication has been completely re-written for 3.0.

Comment 7

[Uli]

(In reply to comment #6)
> Well, I'll at least re-open it.
> 
> I think there are a few issues here, the most important being that different
> LDAP servers work differently, and different people have different schemas.

I believe the most important schema is that used by pam_ldap, i.e. objectClasses posixAccount/posixGroup, because most people will probably want to use their existing unix groups for authentication in bugzilla.

> I don't understand why the LDAPfilter in Bugzilla 3.0 doesn't work for
> you--look at the new code, not the 2.22 code. Authentication has been
> completely re-written for 3.0.

I checked out cvs head and the problem stays the same. There is one query for the users dn, then a bind, and then a query for the users details.

Here is an example of a user and a group entry in posix:
(Beware: the gidNumber field is just the primary group)

dn: cn=Someone Else, ou=people, dc=yourorg, dc=com
cn: Someone Else
sn: Else
objectclass: top
objectclass: person
objectclass: posixAccount
objectclass: shadowAccount
uid:someone
userpassword:{crypt}$1$ss2ii(0$gbs*do&@=)eksd
uidnumber:104
gidnumber:100
gecos:Giuseppe Lo Biondo
loginShell:/bin/zsh
homeDirectory: /home/giuseppe
shadowLastChange:10877
shadowMin: 0
shadowMax: 999999
shadowWarning: 7
shadowInactive: -1
shadowExpire: -1
shadowFlag: 0

dn: cn=mygroup, ou=groups, dc=yourorg, dc=com
objectclass: top
objectclass: posixGroup
cn: mygroup
gidnumber: 100
memberuid: someone
memberuid: anotheruser

Since the cn=mygroup entry is never pulled from LDAP, it is impossible to figure out whether "Someone Else" belongs to mygroup or not.
You don't get around doing another query for the group entry.
If it were SQL and not LDAP, you might do a join like "select * from user join group on (user.uid in group.memberuids) where uid=someone and groupname=mygroup". Well, but it isn't :)

Comment 8

[Max Kanat-Alexander]

(In reply to comment #7)
> I believe the most important schema is that used by pam_ldap, i.e.
> objectClasses posixAccount/posixGroup, because most people will probably want
> to use their existing unix groups for authentication in bugzilla.

  Actually, you're the first person I've ever heard say that you wanted that specifically.

  I get more questions about Active Directory.

> Here is an example of a user and a group entry in posix:
> (Beware: the gidNumber field is just the primary group)
> [snip]

  Okay, I see what you're talking about now.

  The thing I need to see is a standard. I need to see some RFC or to know what OpenLDAP standardly does to represent that a user is in a group. I only want to implement two solutions: one for general use, and one for Active Directory. So the first one needs to be some standard.

Comment 9

[Uli]

(In reply to comment #8)
> (In reply to comment #7)
> > I believe the most important schema is that used by pam_ldap, i.e.
> > objectClasses posixAccount/posixGroup, because most people will probably want
> > to use their existing unix groups for authentication in bugzilla.
> 
>   Actually, you're the first person I've ever heard say that you wanted that
> specifically.

That surprises me.

>   I get more questions about Active Directory.

Ok, that doesn't surprise me :)
Luckily, there are enough non-M$ users in our company to justify a second LDAP infrastructure for *NIX systems.

> > Here is an example of a user and a group entry in posix:
> > (Beware: the gidNumber field is just the primary group)
> > [snip]
> 
>   Okay, I see what you're talking about now.
> 
>   The thing I need to see is a standard. I need to see some RFC or to know what
> OpenLDAP standardly does to represent that a user is in a group. I only want to
> implement two solutions: one for general use, and one for Active Directory. So
> the first one needs to be some standard.

That would be RFC2307:

"An Approach for Using LDAP as a Network Information Service"

There was a draft rfc2307bis that was supposed to replace rfc2307, but it expired. Anyway, it seems that the general layout for groups stayed the same.

nss_ldap and pam_ldap claim to support AIX, HP-UX, *BSD, Mac OS X, Linux and Solaris. See also http://www.padl.com/OSS/pam_ldap.html.

Comment 10

[frank mcpherson]

I agree it's surprising that no one else has asked for this feature.

I'm interested in verifying membership in one or more of a set of groups. For example, my LDAP directory has one group for members of a certain department, Engineering. Everyone in Engineering gets access to Bugzilla. However, there are other people who authenticate on the same LDAP server who aren't in Engineering, and I'd like to give some of them access, so I created another group for that. 

I've got a patch to LDAP.pm that takes care of this and I can submit it if there's interest. 

Comment 11

[Max Kanat-Alexander]

Frank -- Feel free to attach it, and read the Contributor's Guide:

  http://www.bugzilla.org/docs/contributor.html

Also explain why LDAPFilter won't do what you need.

Comment 12

[frank mcpherson]

Max, 
The LDAPFilter won't work(In reply to comment #11)
> Also explain why LDAPFilter won't do what you need.

My reasoning is just about the same as Uli explained in Comment #7: LDAPfilter won't work for checking group membership because primary group membership is contained in the user's entry in the LDAP server, but any secondary group memberships are contained in the Group's entry. I have been unable to find any references to using LDAP filters to filter entries based on the contents of other entries. This would be simple to accomplish using SQL, but as far as I know, LDAP filters don't possess this capability. 

Comment 13

[Klaas Gadeyne]

(In reply to comment #10)
> I agree it's surprising that no one else has asked for this feature.

There is somebody now :-)
Basically, we are having the same problem as uli described in comment #7 (only difference is we're not using posix groups but "just" groupOfNames)

It took me quit a while though, after trying the instructions at
<http://bugzilla.glob.com.au/activedirectory/>
and related ldapsearch queries to the server to figure out that the memberof attribute is active "directory only" (See eg. <http://www.openldap.org/lists/openldap-software/200606/msg00244.html>)
and hence the LDAPfilter approach from current bugzilla implementations won't work for our setup.

> I'm interested in verifying membership in one or more of a set of groups. For
> example, my LDAP directory has one group for members of a certain department,
> Engineering. Everyone in Engineering gets access to Bugzilla. However, there
> are other people who authenticate on the same LDAP server who aren't in
> Engineering, and I'd like to give some of them access, so I created another
> group for that. 
> 
> I've got a patch to LDAP.pm that takes care of this and I can submit it if
> there's interest. 

There is some interest now.  Could you please attach it to this bugreport?

Thx,

Klaas

Comment 15

[Stephen Reindl]

Attachment: Grant permission to login based on membership in a posix group (Bugzilla 3.1.4)

The attachment is a patch based on 3.1.4. It adds (as in te previous patch) a new parameter LDAPgroup that can contain a LDAP posix group name.

Maybe we want to enhance the filter only to work on posix groups (by adding an filter on objectClass=posixgroup)?

Comment 16

[Stephen Reindl]

btw. I also added some more documentation on LDAPfilter that this filter works only on the user's attribute. 

Comment 17

[Teemu Mannermaa (:wicked)]

Comment on attachment 328148 [details] [diff] [review]
Grant permission to login based on membership in a posix group (Bugzilla 3.1.4)

Mkanat is best bet for authentication system reviews.

Comment 18

[Emmanuel Seyman]

Comment on attachment 328148 [details] [diff] [review]
Grant permission to login based on membership in a posix group (Bugzilla 3.1.4)

The patch works but the error message displayed when someone logs in with his LDAP username and password is "The username or password you entered is not valid." which, strictly speaking, isn't true.

Comment 19

[Stephen Reindl]

(In reply to comment #18)
> (From update of attachment 328148 [details] [diff] [review])
> The patch works but the error message displayed when someone logs in with his
> LDAP username and password is "The username or password you entered is not
> valid." which, strictly speaking, isn't true.

What do you expect? 
AUTH_NO_SUCH_USER?

Comment 20

[Michael Bellomo]

We're using the LDAPfilter attribute to accomplish this.  No patch needed.