RE: [Fedora-directory-users] Server-Side ACLs for pam_ldap logins.

[Jason Hane]

I second that.  Dan if you can provide any resources you used to set up
your netgroups I would hail at your feet.  I've been playing with
netgroups unsuccessfully for the past month and a half and haven't been
able to get it to work.  All my clients are RedHat ES 3&4.

-----Original Message-----
From: fedora-directory-users-bounces(a)redhat.com
[mailto:[e-mail]] On Behalf Of Richard
Megginson
Sent: Tuesday, January 03, 2006 4:06 PM
To: General discussion list for the Fedora Directory server project.
Subject: Re: [Fedora-directory-users] Server-Side ACLs for pam_ldap
logins.

This looks very interesting and useful.  Would you mind writing up
something I can post on the Fedora DS wiki?  Don't worry about
formatting, spelling, etc.  I can fix that up.

Dan Cox wrote:

>  As an alternative, I've used the ldap/netgroup integration for many 
>  years and it seems the cleanest way of doing it when used in 
>  conjunction with pam's access.conf. It allows me to push the same 
>  /etc/passwd and /etc/security/access.conf to all machines on the 
>  network via something like CFEngine.
>
>  The access.conf consists of something like (allow all QA users access 
>  to QA systems):
>  + : @QA@@QAServers : ALL
>
>  Then I just add or remove the user or machine in the ldap netgroup 
>  entry. The real power with using ldap based netgroups is when you 
>  realize all of the services that can consume netgroup information, 
>  unlike the simple user based host attribute. For example, you can push 
>  a global /etc/sudoers and specify certain groups of users can run 
>  certain commands on particular groups of machines all on one line.
>  CFEngine itself can query netgroups to know what config files to push, 
>  tools like dsh (distributed ssh) can use netgroups as machine targets
>
>  for commands, etc. I've administered some very large networks of 
>  machines with these tools and it makes it very easy to control.
>
>  Dan-
>
>  Jason Hane wrote:
>
> > I had a similar question a few weeks ago.  I wanted to be able to 
> > assign a list of users access to only a specific number of computers. 
> > This is the response I got from Gary Tay:
> >
> > FDS is very similar to SUN ONE DS5.2, I think netgroup (+@netgroupXXX 
> > in /etc/passwd and /etc/shadow and "compat" keyword in
>
> > /etc/nsswitch.conf) LDAP maps could be setup to achieve what you 
> > want, it has been used by many DS5.2 administrators
> >
> > See:
> > http://web.singnet.com.sg/~garyttt/Installing%20and%20configuring%20O
> > pen LDAP%20for%20RedHat%20Enterprise%20Linux3.htm
> > Step 5Y: Configure "netgroup" to work with RedHat or Solaris Native 
> > LDAP Clients (i.e. controlling user access to host using netgroup 
> > LDAP maps)
> >
> > Also see:
> > http://swforum.sun.com/jive/thread.jspa?threadID=52764&messageID=2238
> > 46#
> > 223846
> > Configuring LDAP netgroups
> > Gary
> > -----Original Message-----
> > From: fedora-directory-users-bounces(a)redhat.com
> > [mailto:[e-mail]] On Behalf Of 
> > Michael Montgomery
> > Sent: Tuesday, January 03, 2006 1:35 PM
> > To: General discussion list for the Fedora Directory server project.
> > Subject: Re: [Fedora-directory-users] Server-Side ACLs for pam_ldap 
> > logins.
> >
> > Thanks for the response.  I'll read up on this, and see if I can get 
> > this working.
> >
> > On Tue, 2006-01-03 at 11:29 -0700, Richard Megginson wrote:
> >  
> >
> >> Michael Montgomery wrote:
> >>
> >>   
> >>
> >>> I do agree that this is closer to what I'm looking for, but the 
> >>> first
> >>>     
> >>
> >
> >  
> >
> >>> problem I see is that I wanted to allow Groups of people to login 
> >>> to Groups of servers like:
> >>>
> >>> cn=www,ou=Group,dc=example,dc=com  is a group of www servers.
> >>> cn=Unix,ou=Group,dc=example,dc=com  is a group of Unix users.
> >>>
> >>> So basically, on the people in the Unix group, can login to the www 
> >>> servers, and so forth.
> >>>
> >>>
> >>>     
> >>
> >> Right.  The host attribute is per user.  You could set up a Roles 
> >> for your users, and use Class of Service to automatically add the 
> >> host attribute to the role members.
> >>   
> >
> >
> >
> > --
> > Fedora-directory-users mailing list
> > Fedora-directory-users(a)redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-directory-users
> >
> > --
> > Fedora-directory-users mailing list
> > Fedora-directory-users(a)redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-directory-users
> >  
> >
>
>  --
>  Fedora-directory-users mailing list
>  Fedora-directory-users(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-directory-users

[Fedora-directory-users] Server-Side ACLs for pam_ldap logins.

[Dan Cox]

I suppose I could put something together.. are you talking about 
something from the ground up like setting up nss_ldap, adding entries 
into LDAP, etc. or assume some of the prerequisites are in place? Also 
I'm assuming some short example usages of the tools I've mentioned?

Dan-

Jason Hane wrote:

> I second that.  Dan if you can provide any resources you used to set
> up
> your netgroups I would hail at your feet.  I've been playing with
> netgroups unsuccessfully for the past month and a half and haven't been
> able to get it to work.  All my clients are RedHat ES 3&4.
>
> -----Original Message-----
> From: fedora-directory-users-bounces(a)redhat.com
> [mailto:[e-mail]] On Behalf Of Richard
> Megginson
> Sent: Tuesday, January 03, 2006 4:06 PM
> To: General discussion list for the Fedora Directory server project.
> Subject: Re: [Fedora-directory-users] Server-Side ACLs for pam_ldap
> logins.
>
> This looks very interesting and useful.  Would you mind writing up
> something I can post on the Fedora DS wiki?  Don't worry about
> formatting, spelling, etc.  I can fix that up.
>
> Dan Cox wrote:
>
>   
>
> >As an alternative, I've used the ldap/netgroup integration for many 
> >years and it seems the cleanest way of doing it when used in 
> >conjunction with pam's access.conf. It allows me to push the same 
> >/etc/passwd and /etc/security/access.conf to all machines on the 
> >network via something like CFEngine.
> >
> >The access.conf consists of something like (allow all QA users access 
> >to QA systems):
> >+ : @QA@@QAServers : ALL
> >
> >Then I just add or remove the user or machine in the ldap netgroup 
> >entry. The real power with using ldap based netgroups is when you 
> >realize all of the services that can consume netgroup information, 
> >unlike the simple user based host attribute. For example, you can push
> >    
> >
>
>   
>
> >a global /etc/sudoers and specify certain groups of users can run 
> >certain commands on particular groups of machines all on one line.
> >CFEngine itself can query netgroups to know what config files to push,
> >    
> >
>
>   
>
> >tools like dsh (distributed ssh) can use netgroups as machine targets 
> >for commands, etc. I've administered some very large networks of 
> >machines with these tools and it makes it very easy to control.
> >
> >Dan-
> >
> >Jason Hane wrote:
> >
> >    
> >
> >>I had a similar question a few weeks ago.  I wanted to be able to 
> >>assign a list of users access to only a specific number of computers.
> >>      
> >>
>
>   
>
> >>This is the response I got from Gary Tay:
> >>
> >>FDS is very similar to SUN ONE DS5.2, I think netgroup (+@netgroupXXX
> >>      
> >>
>
>   
>
> >>in /etc/passwd and /etc/shadow and "compat" keyword in 
> >>/etc/nsswitch.conf) LDAP maps could be setup to achieve what you 
> >>want, it has been used by many DS5.2 administrators
> >>
> >>See:
> >>http://web.singnet.com.sg/~garyttt/Installing%20and%20configuring%20O
> >>pen LDAP%20for%20RedHat%20Enterprise%20Linux3.htm
> >>Step 5Y: Configure "netgroup" to work with RedHat or Solaris Native 
> >>LDAP Clients (i.e. controlling user access to host using netgroup 
> >>LDAP maps)
> >>
> >>Also see:
> >>http://swforum.sun.com/jive/thread.jspa?threadID=52764&messageID=2238
> >>46#
> >>223846
> >>Configuring LDAP netgroups
> >>Gary
> >>-----Original Message-----
> >>From: fedora-directory-users-bounces(a)redhat.com
> >>[mailto:[e-mail]] On Behalf Of 
> >>Michael Montgomery
> >>Sent: Tuesday, January 03, 2006 1:35 PM
> >>To: General discussion list for the Fedora Directory server project.
> >>Subject: Re: [Fedora-directory-users] Server-Side ACLs for pam_ldap 
> >>logins.
> >>
> >>Thanks for the response.  I'll read up on this, and see if I can get 
> >>this working.
> >>
> >>On Tue, 2006-01-03 at 11:29 -0700, Richard Megginson wrote:
> >> 
> >>
> >>      
> >>
> >>>Michael Montgomery wrote:
> >>>
> >>>  
> >>>
> >>>        
> >>>
> >>>>I do agree that this is closer to what I'm looking for, but the 
> >>>>first
> >>>>    
> >>>>          
> >>>>
> >> 
> >>
> >>      
> >>
> >>>>problem I see is that I wanted to allow Groups of people to login 
> >>>>to Groups of servers like:
> >>>>
> >>>>cn=www,ou=Group,dc=example,dc=com  is a group of www servers.
> >>>>cn=Unix,ou=Group,dc=example,dc=com  is a group of Unix users.
> >>>>
> >>>>So basically, on the people in the Unix group, can login to the www
> >>>>          
> >>>>
>
>   
>
> >>>>servers, and so forth.
> >>>>
> >>>>
> >>>>    
> >>>>          
> >>>>
> >>>Right.  The host attribute is per user.  You could set up a Roles 
> >>>for your users, and use Class of Service to automatically add the 
> >>>host attribute to the role members.
> >>>  
> >>>        
> >>>
> >>
> >>--
> >>Fedora-directory-users mailing list
> >>Fedora-directory-users(a)redhat.com
> >>https://www.redhat.com/mailman/listinfo/fedora-directory-users
> >>
> >>--
> >>Fedora-directory-users mailing list
> >>Fedora-directory-users(a)redhat.com
> >>https://www.redhat.com/mailman/listinfo/fedora-directory-users
> >> 
> >>
> >>      
> >>
> >--
> >Fedora-directory-users mailing list
> >Fedora-directory-users(a)redhat.com
> >https://www.redhat.com/mailman/listinfo/fedora-directory-users
> >    
> >
>
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users(a)redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>   
>

[Fedora-directory-users] Server-Side ACLs for pam_ldap logins.

[Rich Megginson]

Dan Cox wrote:

>  I suppose I could put something together.. are you talking about 
>  something from the ground up like setting up nss_ldap, adding entries 
>  into LDAP, etc. or assume some of the prerequisites are in place? 
If there is already sufficient documentation on setting up nss_ldap or 
other prerequisites, then just a pointer to that will be fine.

>  Also I'm assuming some short example usages of the tools I've
> mentioned? 
Sure.  At least on group based host access restriction, which seems to 
be the most asked for info.

>  Dan-
>
>  Jason Hane wrote:
>
> > I second that.  Dan if you can provide any resources you used to set up
> > your netgroups I would hail at your feet.  I've been playing with
> > netgroups unsuccessfully for the past month and a half and haven't been
> > able to get it to work.  All my clients are RedHat ES 3&4.
> >
> > -----Original Message-----
> > From: fedora-directory-users-bounces(a)redhat.com
> > [mailto:[e-mail]] On Behalf Of Richard
> > Megginson
> > Sent: Tuesday, January 03, 2006 4:06 PM
> > To: General discussion list for the Fedora Directory server project.
> > Subject: Re: [Fedora-directory-users] Server-Side ACLs for pam_ldap
> > logins.
> >
> > This looks very interesting and useful.  Would you mind writing up
> > something I can post on the Fedora DS wiki?  Don't worry about
> > formatting, spelling, etc.  I can fix that up.
> >
> > Dan Cox wrote:
> >
> >  
> >
> >> As an alternative, I've used the ldap/netgroup integration for many 
> >> years and it seems the cleanest way of doing it when used in 
> >> conjunction with pam's access.conf. It allows me to push the same 
> >> /etc/passwd and /etc/security/access.conf to all machines on the 
> >> network via something like CFEngine.
> >>
> >> The access.conf consists of something like (allow all QA users 
> >> access to QA systems):
> >> + : @QA@@QAServers : ALL
> >>
> >> Then I just add or remove the user or machine in the ldap netgroup 
> >> entry. The real power with using ldap based netgroups is when you 
> >> realize all of the services that can consume netgroup information, 
> >> unlike the simple user based host attribute. For example, you can push
> >>   
> >
> >
> >  
> >
> >> a global /etc/sudoers and specify certain groups of users can run 
> >> certain commands on particular groups of machines all on one line.
> >> CFEngine itself can query netgroups to know what config files to push,
> >>   
> >
> >
> >  
> >
> >> tools like dsh (distributed ssh) can use netgroups as machine 
> >> targets for commands, etc. I've administered some very large 
> >> networks of machines with these tools and it makes it very easy to 
> >> control.
> >>
> >> Dan-
> >>
> >> Jason Hane wrote:
> >>
> >>   
> >>
> >>> I had a similar question a few weeks ago.  I wanted to be able to 
> >>> assign a list of users access to only a specific number of computers.
> >>>     
> >>
> >
> >  
> >
> >>> This is the response I got from Gary Tay:
> >>>
> >>> FDS is very similar to SUN ONE DS5.2, I think netgroup (+@netgroupXXX
> >>>     
> >>
> >
> >  
> >
> >>> in /etc/passwd and /etc/shadow and "compat" keyword in 
> >>> /etc/nsswitch.conf) LDAP maps could be setup to achieve what you 
> >>> want, it has been used by many DS5.2 administrators
> >>>
> >>> See:
> >>> http://web.singnet.com.sg/~garyttt/Installing%20and%20configuring%20O
> >>> pen LDAP%20for%20RedHat%20Enterprise%20Linux3.htm
> >>> Step 5Y: Configure "netgroup" to work with RedHat or Solaris Native
>
> >>> LDAP Clients (i.e. controlling user access to host using netgroup 
> >>> LDAP maps)
> >>>
> >>> Also see:
> >>> http://swforum.sun.com/jive/thread.jspa?threadID=52764&messageID=2238
> >>> 46#
> >>> 223846
> >>> Configuring LDAP netgroups
> >>> Gary
> >>> -----Original Message-----
> >>> From: fedora-directory-users-bounces(a)redhat.com
> >>> [mailto:[e-mail]] On Behalf Of 
> >>> Michael Montgomery
> >>> Sent: Tuesday, January 03, 2006 1:35 PM
> >>> To: General discussion list for the Fedora Directory server project.
> >>> Subject: Re: [Fedora-directory-users] Server-Side ACLs for pam_ldap 
> >>> logins.
> >>>
> >>> Thanks for the response.  I'll read up on this, and see if I can 
> >>> get this working.
> >>>
> >>> On Tue, 2006-01-03 at 11:29 -0700, Richard Megginson wrote:
> >>>
> >>>
> >>>     
> >>>
> >>>> Michael Montgomery wrote:
> >>>>
> >>>>  
> >>>>
> >>>>       
> >>>>
> >>>>> I do agree that this is closer to what I'm looking for, but the 
> >>>>> first
> >>>>>            
> >>>>
> >>>
> >>>
> >>>     
> >>>
> >>>>> problem I see is that I wanted to allow Groups of people to login 
> >>>>> to Groups of servers like:
> >>>>>
> >>>>> cn=www,ou=Group,dc=example,dc=com  is a group of www servers.
> >>>>> cn=Unix,ou=Group,dc=example,dc=com  is a group of Unix users.
> >>>>>
> >>>>> So basically, on the people in the Unix group, can login to the www
> >>>>>         
> >>>>
> >
> >  
> >
> >>>>> servers, and so forth.
> >>>>>
> >>>>>
> >>>>>            
> >>>>
> >>>> Right.  The host attribute is per user.  You could set up a Roles 
> >>>> for your users, and use Class of Service to automatically add the 
> >>>> host attribute to the role members.
> >>>>  
> >>>>       
> >>>
> >>>
> >>> -- 
> >>> Fedora-directory-users mailing list
> >>> Fedora-directory-users(a)redhat.com
> >>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
> >>>
> >>> -- 
> >>> Fedora-directory-users mailing list
> >>> Fedora-directory-users(a)redhat.com
> >>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
> >>>
> >>>
> >>>     
> >>
> >> -- 
> >> Fedora-directory-users mailing list
> >> Fedora-directory-users(a)redhat.com
> >> https://www.redhat.com/mailman/listinfo/fedora-directory-users
> >>   
> >
> >
> >
> > -- 
> > Fedora-directory-users mailing list
> > Fedora-directory-users(a)redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-directory-users
> >  
> >
>
>  -- 
>  Fedora-directory-users mailing list
>  Fedora-directory-users(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-directory-users

[Fedora-directory-users] Server-Side ACLs for pam_ldap logins.

[Dan Cox]

Since I've been meaning to write this document for quite a while now it 
got a bit long so feel free to trim it as needed. I concentrated mainly 
on how to implement login access control, but left some references to 
other possibilities. It may need to have some URL references added when 
it makes its way to the WIKI. I've attached it in OpenDocument  form as 
well, which may be easier to read.


*System Access Control using LDAP backed NIS Netgroups*


There are many ways to control both login and service level 
authentication with Fedora Directory Server. Here, I will discuss a 
specific implementation using LDAP backed NIS Netgroups and detail what 
exactly makes them so powerful.

/Prerequisites/

    *

      Some knowledge of NIS and the netgroup triple syntax is in order.
      For those that do not have a netgroup man page available, you may
      see the Sun NIS FAQ http://www.sunhelp.org/faq/nis.html, Section
      3.15 specifically.

    *

      An understanding of PAM and the PAM module stack.

    *

      A working implementation of nss_ldap, which acts as the
      NSS->NIS->LDAP gateway is required.

/What are NIS netgroups good for?/

First, it's important to understand what a NIS netgroup gains the 
average system administrator. NIS Netgroups provide the ability to 
perform such tasks as:

    *

      Control both user and group login access to individual or groups
      of machines.

    *

      Manage NFS access control lists.

    *

      Control user and group sudo command access.

    *

      Execute remote commands or interactive logins on groups of
      machines with dsh (distributed shell).

    *

      Manage the configuration of your entire network on a role basis
      with CFEngine.

These are just a few of the excellent uses for NIS netgroups. If we take 
this functionality and implement an LDAP based backend, we can not only 
take advantage of these tools but gain the security, manageability and 
fault tolerance of Fedora Directory Server.

/How does it work?/

NIS netgroup entries are stored as an objectClass of type nisNetgroup in 
the directory server. The relative distinguished name attribute is 
typically cn (common name). There are two important attributes in 
creating the netgroup. Note that they are not mutually exclusive. Also, 
neither are required (sometimes having an empty netgroup is as valuable 
as one populated with values).

    *

      nisNetgroupTriple : This can be used to describe a user
      (,bobby,example.com) or a machine name
      (shellserver1,,example.com). This attribute can have multiple values.

    *

      memberNisNetgroup : This is a very powerful attribute. It is used
      to merge the attribute values of another netgroup into the current
      one by simply listing the name (cn) of the merging netgroup. This
      attribute can have multiple values as well.

You also want to attach a description attribute and value to your 
object. You were planning on describing that netgroup, weren't you?

Let's look at an example LDIF:

dn: cn=QAUsers,ou=Netgroup,dc=example,dc=com

objectClass: nisNetgroup

objectClass: top

cn: QAUsers

nisNetgroupTriple: (,bobby,example.com)

nisNetgroupTriple: (,joey,example.com)

description: All QA users in my organization

We can see here that the users 'bobby' and 'joey' belong to the QAUsers 
netgroup. Now, any tool that will query for the QAUsers netgroup will 
get back these values and can act upon them.

With nss_ldap appropriately configured and /etc/nsswitch.conf 
conveniently pointing netgroup queries to ldap, we can test this entry 
on the command line like so:

# getent netgroup QAUsers

QAUsers (,bobby,example.com) (,joey,example.com)

The getent command is part of the glibc-common package on Fedora. It can 
be used to query any of the available NSS databases.

Now, let's look at an LDIF defining which machines are QA systems on our 
network:

dn: cn=QASystems,ou=Netgroup,dc=example,dc=com

objectClass: nisNetgroup

objectClass: top

cn: QASystems

nisNetgroupTriple: (qa01,,example.com)

nisNetgroupTriple: (qa02,,example.com)

description: All QA systems on our network

OK, so we have our users and systems in place, now how do we give 
QAUsers login access to QASystems? Enter PAM's access.conf.

PAM has an often overlooked access control feature, the configuration of 
which is typically located in /etc/security/access.conf. It has the 
ability to use UNIX users and groups as well as NIS netgroups to control 
remote and local console access to the system. The documentation of the 
syntax should be contained within the configuration file itself.

We can give our users remote login access from our 10.x.x.x network with 
this line:

    *

      : @QAUsers@@QASystems : 10.

*NOTE*: PAM operates on a first match basis for granting access. This 
means you want to end your ACL list by denying all unmatched entries, 
but before you do that make sure root and/or your admin users have been 
matched! For example, adding root for console only, users in the Admins 
netgroup remote access and denying all other unmatched entries:

+ : root : LOCAL

+ : @Admins : 10.

- : ALL : ALL

An advantage to using machine groups in the access.conf is the ability 
to push out this access.conf configuration file to all systems in your 
network, regardless if they are related to QA. This gives an admin the 
ability to maintain a central access control list of general user and 
group pairs, which can be deployed via tools like CFEngine. If a QA user 
attempts to login to a non-QA system, PAM will first check for the 
user's name in the users portion of the ACL. If a match is found, it 
will then check if the current machine's hostname exists in the netgroup 
or machine name section. If the current machine does not belong to the 
netgroup, the ACL fails and the next one will be tried.

Since we have created our own framework of system and user group ACLs 
inside the LDAP server, we have decoupled access control from the actual 
posixAccount and posixGroup entries. This means that the user no longer 
requires an account in the LDAP server itself. A simple entry in 
/etc/passwd is good enough to apply access control in this manor.

With this infrastructure in place, we can now start up Fedora's Admin 
Console or our favorite LDAP editor and quickly add or remove login 
access to users and machines!

/Advanced Usage & Tips/

Use sub scope for your netgroup queries as configured in /etc/ldap.conf. 
This will give you the ability to create new netgroups inside 
organizationalUnit and other containers, which will help categorize your 
ACLs. nss_ldap is smart enough to only match objects of type nisNetgroup 
when performing its searches.

With the memberNisNetgroup attribute, we can join together our netgroups 
to achieve cascading access control and system groupings. What if the 
QAUsers bobby and joey were also members of a larger team called 
LinuxTeam, which contains individuals who aren't in QA? An example LDIF 
defining the LinuxTeam:

dn: cn=LinuxTeam,ou=Netgroup,dc=example,dc=com

objectClass: nisNetgroup

objectClass: top

cn: LinuxTeam

nisNetgroupTriple: (,frank,example.com)

nisNetgroupTriple: (,jill,example.com)

memberNisNetgroup: QA

memberNisNetgroup: Development

memberNisNetgroup: Operations

description: The Linux Team

Here we have defined some new users frank and jill as being part of the 
LinuxTeam. We have also automatically imported bobby and joey from the 
QA team as well as any additional users defined in our hypothetical 
Development and Operations groups. Any ACL for the LinuxTeam deployed on 
our network will not only apply to frank and jill, but to all imported 
users!

You may have noticed the nisNetgroupTriple's example.com entry. This is 
an indicator to NIS netgroup clients that the result of the netgroup 
query should only apply to servers in the example.com domain. If you 
have multiple domains, this can be a useful feature to further separate 
your ACLs. It's also completely optional. Leaving this portion of the 
triple empty will remove the domain restriction.

It's worth noting that the LDAP backend implementation discussed here 
can be implemented in other directory servers include Active Directory. 
Also, client functionality can be applied to most modern, PAM enabled 
UNIX systems such as Linux and Solaris.

I hope this information will be useful for systems administrators out 
there trying to implement centralized and maintainable access control in 
their Linux/UNIX network. It can be done!

Dan Cox

[Fedora-directory-users] Server-Side ACLs for pam_ldap logins.

[Rich Megginson]

Thanks!  This is excellent!
http://directory.fedora.redhat.com/wiki/Howto:Netgroups

Dan Cox wrote:

>  Since I've been meaning to write this document for quite a while now 
>  it got a bit long so feel free to trim it as needed. I concentrated 
>  mainly on how to implement login access control, but left some 
>  references to other possibilities. It may need to have some URL 
>  references added when it makes its way to the WIKI. I've attached it 
>  in OpenDocument  form as well, which may be easier to read.
>
>
>  *System Access Control using LDAP backed NIS Netgroups*
>
>
>  There are many ways to control both login and service level 
>  authentication with Fedora Directory Server. Here, I will discuss a 
>  specific implementation using LDAP backed NIS Netgroups and detail 
>  what exactly makes them so powerful.
>
>  /Prerequisites/
>
>     *
>
>       Some knowledge of NIS and the netgroup triple syntax is in order.
>       For those that do not have a netgroup man page available, you may
>       see the Sun NIS FAQ http://www.sunhelp.org/faq/nis.html, Section
>       3.15 specifically.
>
>     *
>
>       An understanding of PAM and the PAM module stack.
>
>     *
>
>       A working implementation of nss_ldap, which acts as the
>       NSS->NIS->LDAP gateway is required.
>
>  /What are NIS netgroups good for?/
>
>  First, it's important to understand what a NIS netgroup gains the 
>  average system administrator. NIS Netgroups provide the ability to 
>  perform such tasks as:
>
>     *
>
>       Control both user and group login access to individual or groups
>       of machines.
>
>     *
>
>       Manage NFS access control lists.
>
>     *
>
>       Control user and group sudo command access.
>
>     *
>
>       Execute remote commands or interactive logins on groups of
>       machines with dsh (distributed shell).
>
>     *
>
>       Manage the configuration of your entire network on a role basis
>       with CFEngine.
>
>  These are just a few of the excellent uses for NIS netgroups. If we 
>  take this functionality and implement an LDAP based backend, we can 
>  not only take advantage of these tools but gain the security, 
>  manageability and fault tolerance of Fedora Directory Server.
>
>  /How does it work?/
>
>  NIS netgroup entries are stored as an objectClass of type nisNetgroup 
>  in the directory server. The relative distinguished name attribute is 
>  typically cn (common name). There are two important attributes in 
>  creating the netgroup. Note that they are not mutually exclusive. 
>  Also, neither are required (sometimes having an empty netgroup is as 
>  valuable as one populated with values).
>
>     *
>
>       nisNetgroupTriple : This can be used to describe a user
>       (,bobby,example.com) or a machine name
>       (shellserver1,,example.com). This attribute can have multiple 
>  values.
>
>     *
>
>       memberNisNetgroup : This is a very powerful attribute. It is used
>       to merge the attribute values of another netgroup into the current
>       one by simply listing the name (cn) of the merging netgroup. This
>       attribute can have multiple values as well.
>
>  You also want to attach a description attribute and value to your 
>  object. You were planning on describing that netgroup, weren't you?
>
>  Let's look at an example LDIF:
>
>  dn: cn=QAUsers,ou=Netgroup,dc=example,dc=com
>
>  objectClass: nisNetgroup
>
>  objectClass: top
>
>  cn: QAUsers
>
>  nisNetgroupTriple: (,bobby,example.com)
>
>  nisNetgroupTriple: (,joey,example.com)
>
>  description: All QA users in my organization
>
>  We can see here that the users 'bobby' and 'joey' belong to the 
>  QAUsers netgroup. Now, any tool that will query for the QAUsers 
>  netgroup will get back these values and can act upon them.
>
>  With nss_ldap appropriately configured and /etc/nsswitch.conf 
>  conveniently pointing netgroup queries to ldap, we can test this entry 
>  on the command line like so:
>
>  # getent netgroup QAUsers
>
>  QAUsers (,bobby,example.com) (,joey,example.com)
>
>  The getent command is part of the glibc-common package on Fedora. It 
>  can be used to query any of the available NSS databases.
>
>  Now, let's look at an LDIF defining which machines are QA systems on 
>  our network:
>
>  dn: cn=QASystems,ou=Netgroup,dc=example,dc=com
>
>  objectClass: nisNetgroup
>
>  objectClass: top
>
>  cn: QASystems
>
>  nisNetgroupTriple: (qa01,,example.com)
>
>  nisNetgroupTriple: (qa02,,example.com)
>
>  description: All QA systems on our network
>
>  OK, so we have our users and systems in place, now how do we give 
>  QAUsers login access to QASystems? Enter PAM's access.conf.
>
>  PAM has an often overlooked access control feature, the configuration 
>  of which is typically located in /etc/security/access.conf. It has the 
>  ability to use UNIX users and groups as well as NIS netgroups to 
>  control remote and local console access to the system. The 
>  documentation of the syntax should be contained within the 
>  configuration file itself.
>
>  We can give our users remote login access from our 10.x.x.x network 
>  with this line:
>
>     *
>
>       : @QAUsers@@QASystems : 10.
>
>  *NOTE*: PAM operates on a first match basis for granting access. This 
>  means you want to end your ACL list by denying all unmatched entries, 
>  but before you do that make sure root and/or your admin users have 
>  been matched! For example, adding root for console only, users in the 
>  Admins netgroup remote access and denying all other unmatched entries:
>
>  + : root : LOCAL
>
>  + : @Admins : 10.
>
>  - : ALL : ALL
>
>  An advantage to using machine groups in the access.conf is the ability 
>  to push out this access.conf configuration file to all systems in your 
>  network, regardless if they are related to QA. This gives an admin the 
>  ability to maintain a central access control list of general user and 
>  group pairs, which can be deployed via tools like CFEngine. If a QA 
>  user attempts to login to a non-QA system, PAM will first check for 
>  the user's name in the users portion of the ACL. If a match is found, 
>  it will then check if the current machine's hostname exists in the 
>  netgroup or machine name section. If the current machine does not 
>  belong to the netgroup, the ACL fails and the next one will be tried.
>
>  Since we have created our own framework of system and user group ACLs 
>  inside the LDAP server, we have decoupled access control from the 
>  actual posixAccount and posixGroup entries. This means that the user 
>  no longer requires an account in the LDAP server itself. A simple 
>  entry in /etc/passwd is good enough to apply access control in this 
>  manor.
>
>  With this infrastructure in place, we can now start up Fedora's Admin 
>  Console or our favorite LDAP editor and quickly add or remove login 
>  access to users and machines!
>
>  /Advanced Usage & Tips/
>
>  Use sub scope for your netgroup queries as configured in 
>  /etc/ldap.conf. This will give you the ability to create new netgroups 
>  inside organizationalUnit and other containers, which will help 
>  categorize your ACLs. nss_ldap is smart enough to only match objects 
>  of type nisNetgroup when performing its searches.
>
>  With the memberNisNetgroup attribute, we can join together our 
>  netgroups to achieve cascading access control and system groupings. 
>  What if the QAUsers bobby and joey were also members of a larger team 
>  called LinuxTeam, which contains individuals who aren't in QA? An 
>  example LDIF defining the LinuxTeam:
>
>  dn: cn=LinuxTeam,ou=Netgroup,dc=example,dc=com
>
>  objectClass: nisNetgroup
>
>  objectClass: top
>
>  cn: LinuxTeam
>
>  nisNetgroupTriple: (,frank,example.com)
>
>  nisNetgroupTriple: (,jill,example.com)
>
>  memberNisNetgroup: QA
>
>  memberNisNetgroup: Development
>
>  memberNisNetgroup: Operations
>
>  description: The Linux Team
>
>  Here we have defined some new users frank and jill as being part of 
>  the LinuxTeam. We have also automatically imported bobby and joey from 
>  the QA team as well as any additional users defined in our 
>  hypothetical Development and Operations groups. Any ACL for the 
>  LinuxTeam deployed on our network will not only apply to frank and 
>  jill, but to all imported users!
>
>  You may have noticed the nisNetgroupTriple's example.com entry. This 
>  is an indicator to NIS netgroup clients that the result of the 
>  netgroup query should only apply to servers in the example.com domain. 
>  If you have multiple domains, this can be a useful feature to further 
>  separate your ACLs. It's also completely optional. Leaving this 
>  portion of the triple empty will remove the domain restriction.
>
>  It's worth noting that the LDAP backend implementation discussed here 
>  can be implemented in other directory servers include Active 
>  Directory. Also, client functionality can be applied to most modern, 
>  PAM enabled UNIX systems such as Linux and Solaris.
>
>  I hope this information will be useful for systems administrators out 
>  there trying to implement centralized and maintainable access control 
>  in their Linux/UNIX network. It can be done!
>
>  Dan Cox
>
> ------------------------------------------------------------------------
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users(a)redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>

[Fedora-directory-users] Server-Side ACLs for pam_ldap logins.

[Michael Montgomery]

On Wed, 2006-01-04 at 10:52 -0700, Richard Megginson wrote:
>  Thanks!  This is excellent!
>  http://directory.fedora.redhat.com/wiki/Howto:Netgroups
>   
Thank you all very much for this wonderful documentation, but I just
have one last question.  Being that pam_access doesn't seem to exist on
solaris, and freebsd, and I'm trying to implement a full cross platform
authentication system, are their any options that you know of to allow
this type of command:

: @QAUsers@@QASystems : 10.

To restrict access based on the netgroups for these other two Unixes?

Thanks again.

[Fedora-directory-users] Server-Side ACLs for pam_ldap logins.

[Michael Montgomery]

Actually, login.access may fit the bill for freebsd:

http://www.freebsd.org/cgi/man.cgi?query=login.access&sektion=5

So that just leaves Solaris.

On Thu, 2006-01-05 at 13:59 -0600, Michael Montgomery wrote:
>  On Wed, 2006-01-04 at 10:52 -0700, Richard Megginson wrote:
>  > Thanks!  This is excellent!
>  > http://directory.fedora.redhat.com/wiki/Howto:Netgroups
>  > 
>  
>  Thank you all very much for this wonderful documentation, but I just
>  have one last question.  Being that pam_access doesn't seem to exist on
>  solaris, and freebsd, and I'm trying to implement a full cross platform
>  authentication system, are their any options that you know of to allow
>  this type of command:
>  
>  : @QAUsers@@QASystems : 10.
>  
>  To restrict access based on the netgroups for these other two Unixes?
>  
>  Thanks again.