[tac_plus] user DEFAULT - anyone can login?

Asif Iqbal vadud3 at gmail.com
Tue Jun 17 15:08:17 UTC 2014


On Mon, Jun 16, 2014 at 5:52 PM, Aaron Wasserott <
aaron.wasserott at viawest.com> wrote:

>  I think the issue you were seeing with still having access for that user
> is because you have DEFAULT user listed first.  do_auth will act on the
> first match it finds. In my do_auth.ini files I put the DEFAULT user after
> all the specific users as a catch-all.
>

I am failing to connect to any router with this config and not seeing any
log

do_auth.ini
========
[users]
DEFAULT =
    opseng
[opseng]
host_allow =
    .*
device_permit =
    .*
command_deny =
    clear "^route-map counters"
    show "^list"
    debug "^all"
    mpls "traffic-eng attribute-flags"
    no "^ip routing"
    no "^router .*"
    write ^terminal
command_permit =
    clear .*
    show .*
    debug .*
    ## prevent setting admin-group < 2^16... must be 6 decimal digits
    mpls "traffic-eng attribute-flags [0-9][0-9][0-9][0-9][0-9][0-9]"
    mpls .*
    no .*
    write .*

tac_plus.conf
===========
group = doauthaccess {
        default service = permit
        service = exec {
                priv-lvl = 15
                idletime = 10
        }
        after authorization "/usr/bin/python /root/do_auth/do_auth_orig.py
-i $address -u $user -d $name -l /root/do_auth/do_auth.log -f
/root/do_auth/do_auth.ini"
}

user = DEFAULT {
        pap = PAM
        login = PAM
        member = doauthaccess
}

enabled DEBUG on do_auth.py

DEBUG = os.getenv('DEBUG', True)

I am not seeing any log in do_auth.log

What am I doing wrong?



>
>
> *From:* Asif Iqbal [mailto:vadud3 at gmail.com]
> *Sent:* Monday, June 16, 2014 3:20 PM
> *To:* Aaron Wasserott
> *Cc:* tac_plus at shrubbery.net
> *Subject:* Re: [tac_plus] user DEFAULT - anyone can login?
>
>
>
>
>
>
>
> On Mon, Jun 16, 2014 at 5:02 PM, Asif Iqbal <vadud3 at gmail.com> wrote:
>
>
>
>
>
> On Mon, Jun 16, 2014 at 4:20 PM, Aaron Wasserott <
> aaron.wasserott at viawest.com> wrote:
>
> If you use DEFAULT in both tac_plus.conf and do_auth.ini then, no, you
> could not restrict who can login to what. Only restriction there would be
> locking that user account in LDAP/AD to prevent any access for that user.
>
> But you could use DEFAULT in tac_plus.conf and then define users/groups in
> do_auth.ini you can restrict it that way who can login to what.
>
>
>
> device_deny is not being honored.
>
>
>
> [users]
>
> DEFAULT =
>
>     noprivs
>
> iqbala =
>
>     noprivs
>
> [noprivs]
>
> host_deny =
>
>     .*
>
> host_allow =
>
> device_deny =
>
>     .*
>
> device_allow =
>
> command_deny =
>
>     .*
>
> command_permit =
>
>
>
> user ``iqbala'' still can login to a router. command_deny works fine.
>
>
>
> I do not see any log
>
>
>
>
>
>
>
> Oh yeah, DEFAULT on both tac_plus.conf and do_auth.ini and then
> device_deny works.
>
>
>
>
>
>
>
>
>
>
> I remember reading your emails before, and it sounds like you have a
> pretty complicated user base setup. The best way is to model user access
> around the tried-and-true tier groups, like tier1, tier2, tier3. Then you
> could have those three groups defined in tac_plus.conf pointing to
> different do_auth.ini files that control access to certain devices. The big
> issue for you will be something you mentioned a few weeks back, where you
> said you want users in different groups. You might want to think about
> letting more trusted/privileged users have access to things they don't
> necessary need, so you can just stick them in one group like tier2.
>
>
>
>
>
>
>
> So I have over 1500 network devices. Each vendor type gets it own instance
> of tac_plus which can point to
>
> separate do_auth.ini file like you suggested.
>
>
>
> Otherwise I have to consolidate all the devices in permit or deny block
> for different groups. That would be nightmare if I want to consolidate to
> one do_auth.ini file. Plus it will be slow to read through list of devices
> for each authorization request for 1000s of employees. May be there should
> be database option to read for device lists to make it perform well.
>
>
>
>
>
>     -----Original Message-----
> From: tac_plus [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Asif
> Iqbal
> Sent: Monday, June 16, 2014 1:17 PM
> To: tac_plus at shrubbery.net
> Subject: [tac_plus] user DEFAULT - anyone can login?
>
> So if I understand correctly with the following stanza in tac_plus.conf
> anyone with valid LDAP credentials (PAM is pointing to LDAP in my case) can
> login to a router?
>
> user = DEFAULT {
>    login = PAM
>    member = doauthaccess
> }
>
> I am guessing I cannot really use this should I want to limit who can
> login?
>
> I guess I cannot take advantage of do_auth to prevent login since it gets
> called after authorization?
>
> May be I can use do_auth with before authorization as well and define the
> allowed users under the [users] stanza and limti that way if I want to
> shrink my tac_plus conf user blocks to just DEFAULT?
>
> Please advise.
>
> --
> Asif Iqbal
> PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://www.shrubbery.net/pipermail/tac_plus/attachments/20140616/321bd514/attachment.html
> >
> _______________________________________________
> tac_plus mailing list
> tac_plus at shrubbery.net
> http://www.shrubbery.net/mailman/listinfo/tac_plus
>
>
>
>
>
> --
> Asif Iqbal
> PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
>
>
>
>
>
> --
> Asif Iqbal
> PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
>



-- 
Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.shrubbery.net/pipermail/tac_plus/attachments/20140617/c4aa1454/attachment.html>


More information about the tac_plus mailing list