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

Wed Nov 18 03:16:27 UTC 2009

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
> 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