[tac_plus] Re: Issue with Cisco switch authentication against Microsoft Active Directory
Hailu Meng
hailumeng at gmail.com
Wed Nov 18 04:33:04 UTC 2009
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> 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> 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/5efd6d5b/attachment.html
More information about the tac_plus
mailing list