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

adam prozaconstilts at gmail.com
Fri Nov 20 02:46:29 UTC 2009


Hailu Meng wrote:
> Forgot to post to the mailing list.
> 
> I'm feeling getting close to the end. After modifying the ldap.conf and 
> bind a correct user in my group. Right now I can see the packets 
> snifferred through ethereal shows LDAP found my userid. The packet shows 
> out all the user information from Active Directory. This means LDAP did 
> succeeded in finding my userid. But when I input the password. It just 
> got denied. I'm sure the password is correct. So I doubt it could have 
> some setup about password in ldap.conf is wrong. By the way, I added 
> debug=256 and logdir=/var/log/ldap in ldap.conf, but no log is captured 
> for ldap. Not sure why. Here is my current ldap.conf
> ******************************
> 
>     ********
>     host 10.xx.x.15
>     base ou=User Accounts,dc=home,dc=corp,dc=myhome,dc=org
>     ldap_version 3
>     scope sub
>     binddn CN=test,OU=User Accounts,dc=home,dc=corp,dc=myhome,dc=org
>     bindpw mypass
>     rootbinddn dc=home,dc=corp,dc=myhome,dc=org
>     # The port.
>     # Optional: default is 389. SSL LDAP Port 636
>     port 389
>     # RFC2307bis naming contexts
>     nss_base_passwd dc=home,dc=corp,dc=myhome,dc=org?sub
>     nss_base_shadow dc=home,dc=corp,dc=myhome,dc=org?sub
>     nss_base_group dc=home,dc=corp,dc=myhome,dc=org?sub
>     # RFC 2307 (AD) mappings
>     nss_map_objectclass posixAccount User
>     nss_map_objectclass shadowAccount User
>     nss_map_attribute uid sAMAccountName
>     nss_map_attribute cn sAMAccountName
>     nss_map_attribute gecos cn
> 
>     # PAM_LDAP options
>     pam_login_attribute sAMAccountName
>     pam_filter objectclass=User
>     pam_password ad
>     logdir /var/log/ldap
>     debug 1024
>     ssl no
>     timelimit 30
>     bind_timelimit 30
> 
>     I'm thinking pam_password is wrong? I didn't see any packet in
>     ethereal related to password authentication. So I doubt the password
>     hasn't been sent out to Active Directory. Please help me. Thank you
>     very much!!!
> 
>     Lou 
> 
> 
> 
> On Thu, Nov 19, 2009 at 3:42 PM, Hailu Meng <hailumeng at gmail.com 
> <mailto:hailumeng at gmail.com>> wrote:
> 
>     Hi Adam,
> 
>     I'm feeling getting close to the end. After modifying the ldap.conf
>     and bind a correct user in my group. Right now I can see the packets
>     snifferred through ethereal shows LDAP found my userid. The packet
>     shows out all the user information from Active Directory. This means
>     LDAP did succeeded in finding my userid. But when I input the
>     password. It just got denied. I'm sure the password is correct. So I
>     doubt it could have some setup about password in ldap.conf is wrong.
>     By the way, I added debug=256 and logdir=/var/log/ldap in ldap.conf,
>     but no log is captured for ldap. Not sure why. Here is my current
>     ldap.conf
>     **************************************
>     host 10.xx.x.15
>     base ou=User Accounts,dc=home,dc=corp,dc=myhome,dc=org
>     ldap_version 3
>     scope sub
>     binddn CN=test,OU=User Accounts,dc=home,dc=corp,dc=myhome,dc=org
>     bindpw mypass
>     rootbinddn dc=home,dc=corp,dc=myhome,dc=org
>     # The port.
>     # Optional: default is 389. SSL LDAP Port 636
>     port 389
>     # RFC2307bis naming contexts
>     nss_base_passwd dc=home,dc=corp,dc=myhome,dc=org?sub
>     nss_base_shadow dc=home,dc=corp,dc=myhome,dc=org?sub
>     nss_base_group dc=home,dc=corp,dc=myhome,dc=org?sub
>     # RFC 2307 (AD) mappings
>     nss_map_objectclass posixAccount User
>     nss_map_objectclass shadowAccount User
>     nss_map_attribute uid sAMAccountName
>     nss_map_attribute cn sAMAccountName
>     nss_map_attribute gecos cn
> 
>     # PAM_LDAP options
>     pam_login_attribute sAMAccountName
>     pam_filter objectclass=User
>     pam_password ad
>     logdir /var/log/ldap
>     debug 1024
>     ssl no
>     timelimit 30
>     bind_timelimit 30
> 
>     I'm thinking pam_password is wrong? I didn't see any packet in
>     ethereal related to password authentication. So I doubt the password
>     hasn't been sent out to Active Directory. Please help me. Thank you
>     very much!!!
> 
>     Lou
> 
>     On Wed, Nov 18, 2009 at 6:57 AM, adam <prozaconstilts at gmail.com
>     <mailto:prozaconstilts at gmail.com>> wrote:
> 
>         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>
>             <mailto: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>
>                <mailto: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>
>             <mailto: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.
> 
> 
> 

can you 'su - <user>' on the tacacs server and authenticate?

Strange about the debug...I know I get gobs of output...


More information about the tac_plus mailing list