[tac_plus] Re: Issue with Cisco switch authentication against Microsoft Active Directory

adam prozaconstilts at gmail.com
Wed Nov 18 12:57:44 UTC 2009


Hailu Meng wrote:
> Hi Adam,
> 
> By the way, as you said. It appears I don't need create another new 
> group for this authentication purpose. I already have one group setup 
> and I want every one in this group can be authenticated. And also these 
> users are the members for other groups. Does it matter for this case? I 
> mean one user in multiple groups?
> 
> And how about nss mapping? Do I need do some configuration for them? Like,
> 
> nss_schema              rfc2307bis
> nss_base_passwd         ou=security groups,dc=hq,dc=corp,dc=myhouse,dc=com?sub
> nss_base_shadow         ou=security groups,dc=hq,dc=corp,dc=myhouse,dc=com?sub
> 
> nss_base_group          ou=security groups,dc=hq,dc=corp,dc=myhouse,dc=com?sub
> 
> Thanks.
> 
> Lou
> On Tue, Nov 17, 2009 at 10:11 PM, Hailu Meng <hailumeng at gmail.com 
> <mailto:hailumeng at gmail.com>> wrote:
> 
>     Hi Adam,
> 
>     Thank you very much for replying me so quick. This is really
>     helpful. I will try it tomorrow and let you know what I will find
>     out. Thanks a lot.
> 
>     Appreciated.
> 
>     Lou
> 
> 
>     On Tue, Nov 17, 2009 at 9:16 PM, adam <prozaconstilts at gmail.com
>     <mailto:prozaconstilts at gmail.com>> wrote:
> 
>         Hailu Meng wrote:
> 
>             Hi all,
> 
>             I'm trying to set up tac_plus in CentOS 5.3. tac_plus has
>             been compiled with
>             pam and tcp_wrapper. I configured my switch as below:
> 
>             aaa new-model
>             aaa authentication login default group tacacs+ local-case
>             aaa authentication enable default group tacacs+ enable
>             aaa authorization exec default tacacs+
>             aaa accounting exec default start-stop tacacs+
>             aaa accounting network start-stop tacacs+
>             tacacs+ host 10.0.0.11
>             tacacs+ key mykey
> 
>             I configured /etc/tac_plus.conf to use local setting
>             firstly. It worked.
>             Then I tried to use pam with ldap to authenticate against
>             the microsoft
>             active directory. I snifferred the traffic and saw there was
>             an error when
>             my tacacs server was doing query against Active Directory.
>             The error
>             is *problem
>             2001* (*NO_OBJECT*).
> 
>             Do you guys have similar problem when you set up this kind of
>             authentication? I listed the main configuration files below:
>             **************************************************************
>             /etc/pam.d/tac_plus
> 
>             #%PAM-1.0
>             auth       include      system-auth
>             account    required     pam_nologin.so
>             account    include      system-auth
>             password   include      system-auth
>             session    optional     pam_keyinit.so force revoke
>             session    include      system-auth
>             session    required     pam_loginuid.so
> 
>             *********************************************
>             /etc/pam.d/system-auth
> 
>             #%PAM-1.0
>             # This file is auto-generated.
>             # User changes will be destroyed the next time authconfig is
>             run.
>             auth        required      pam_env.so
>             auth        sufficient    pam_unix.so nullok try_first_pass
>             auth        requisite     pam_succeed_if.so uid >= 500 quiet
>             auth        sufficient    pam_ldap.so use_first_pass
>             auth        required      pam_deny.so
> 
>             account     required      pam_unix.so broken_shadow
>             account     sufficient    pam_localuser.so
>             account     sufficient    pam_succeed_if.so uid < 500 quiet
>             account     [default=bad success=ok user_unknown=ignore]
>             pam_ldap.so
>             account     required      pam_permit.so
> 
>             password    requisite     pam_cracklib.so try_first_pass retry=3
>             password    sufficient    pam_unix.so md5 shadow nullok
>             try_first_pass
>             use_authtok
>             password    sufficient    pam_ldap.so use_authtok
>             password    required      pam_deny.so
> 
>             session     optional      pam_keyinit.so revoke
>             session     required      pam_limits.so
>             session     [success=1 default=ignore] pam_succeed_if.so
>             service in
>             crond quiet use_uid
>             session     required      pam_unix.so
>             session     required      pam_mkhomedir.so skel=/etc/skel/
>             umask=0077
>             session     optional      pam_ldap.so
> 
>             *******************************************************8
>             /etc/ldap.conf
> 
> 
>             host 10.0.0.100
>             base    ou=security groups,dc=hq,dc=corp,dc=myhouse,dc=com
>             binddn  cn=network services,ou=security
>             groups,dc=hq,dc=corp,dc=myhouse,dc=com
>             #bindpw  ohsosecret  # no secret set
>             scope   sub
>             ssl     no
> 
> 
>             nss_schema              rfc2307bis
>             nss_base_passwd         ou=security
>             groups,dc=hq,dc=corp,dc=myhouse,dc=com?sub
>             nss_base_shadow         ou=security
>             groups,dc=hq,dc=corp,dc=myhouse,dc=com?sub
>             nss_base_group          ou=security
>             groups,dc=hq,dc=corp,dc=myhouse,dc=com?sub
> 
>             referrals       no  # otherwise it goes freakishly slow
> 
>             I linked /etc/openldap/ldap.conf to /etc/ldap.conf. I didn't
>             enable ssl for
>             ldap.
> 
>             I think the problem could be in the configuration of
>             ldap.conf or it doesn't
>             match the configuration in Active Directory. In my AD, I
>             have "security
>             groups" OU and in this OU I have "network services" group.
>             Maybe the issue also stays in nss mapping? I searched some
>             articles. It
>             seems like nss mapping must be correct to authenticate
>             through Linux box
>             against Active Directory.
> 
>             Another question about active directory is: Do I need create
>             a separate OU
>             to hold the user accounts who will have rights to login
>             Cisco devices? I saw
>             someone said the user account in tacacs server must not be
>             in other groups.
>             If the separate OU is needed and the user must be only in
>             this new OU, it
>             will lose the flexibility to use the current Active
>             Directory which is
>             already configured.
> 
>             Please give me some help on this. Very appreciated.
> 
>             Thanks.
> 
>             Lou
>             -------------- next part --------------
>             An HTML attachment was scrubbed...
>             URL:
>             http://www.shrubbery.net/pipermail/tac_plus/attachments/20091117/03eedad2/attachment.html
>             _______________________________________________
>             tac_plus mailing list
>             tac_plus at shrubbery.net <mailto:tac_plus at shrubbery.net>
>             http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus
> 
> 
>         I think you're missing a few key items from your ldap.conf:
> 
>            pam_filter objectclass=User
>            pam_login_attribute sAMAccountName
> 
>         These directives will tell pam pretty much two things:
> 
>         1. pam_filter = an ldap filter that restricts who can actually
>         authenticate. This is wonderfully handy as it lets you build an
>         AD group that you can then look for when you auth a user, and
>         not have to modify your AD structure e.g.
> 
>                pam_filter
>         &(objectclass=User)(member=cn=my_group,ou=my_ou,dc=my_domain)
> 
>         This tells pam that you can only authenticate if you are a
>         "User" (and not a service or other non-person account type), and
>         that you are a member of the group specified. Assuming all your
>         user accounts exist somewhere under the base OU you specified
>         above, this lets you search them out, and use AD groups w/o
>         messing w/ your AD structure.
> 
>         2. pam_login_attribute sAMAccountName
> 
>         By default, when using openldap, logging in as 'joe' causes
>         pam_ldap to look in the LDAP store for a record like
>         uid=joe,(+base). For you, this means pam_ldap will ask the AD
>         for any object that has uid=joe anywhere under your base ou:
>         ou=security groups,dc=hq,dc=corp,dc=myhouse,dc=com.
> 
>         But in Active Directory land, user accounts don't have a 'uid'
>         field that gets populated with your login name, it uses a
>         different field, called sAMAccountName. This directive tells pam
>         to look for sAMAccountName=joe when talking to the active
>         directory, which is what the AD is expecting.
> 
>         Also, you can subtract tac_plus from the mix and just try to
>         make sure pam works. In your ldap.conf, you can put a line like
> 
>                debug 256
> 
>         to get lots of debug into on console and in log files, and then
>         run su - <username>, subbing in your AD user account name. The
>         higher the debug number, the more debug output you'll get.
> 
>         Adam
> 
> 
> 

A user being a member of multiple groups shouldn't be a problem. Just be 
sure that the account you specify for your binddn has the ability to see 
the "memberof" information about your users. Also, you'll probably need 
to specify the password for the network services user in the bindpw for 
it to work...


All the nss bits shouldn't be necessary for pam to work.


More information about the tac_plus mailing list