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

Wed Nov 18 04:11:09 UTC 2009

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> 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
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.shrubbery.net/pipermail/tac_plus/attachments/20091117/5e604f5b/attachment.html 