[tac_plus] user DEFAULT - anyone can login?

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


On Tue, Jun 17, 2014 at 12:44 PM, Asif Iqbal <vadud3 at gmail.com> wrote:

>
>
>
> On Tue, Jun 17, 2014 at 11:08 AM, Asif Iqbal <vadud3 at gmail.com> wrote:
>
>>
>>
>>
>> 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
>>
>
> I guess there is no log because user = DEFAULT {..} block is never
> consulted.
>
> man page says:
>
> "
>          default authentication
>               By  default,  authentication  fails for users that do not
> appear in the configuration file.  This
>               overrides that behavior, thus permitting all authentication
> requests for such users.
>
>                   default authentication = file <filename>
>
>               Such users will be authentication via the <user> "DEFAULT".
> "
>
> So that explains why I do not see any log, since I am not using default
> authentication = file <filename>.
> I am using login = PAM for users.
>
> So to comply with that I added default authentication = file
> /etc/tacacs-passwd and added my account
> in there.
>
> Now I can login with user = DEFAULT {..} and I do see logs and DEBUG logs
> in do_auth.log file.
>
> Is there a way I can make default authentication = PAM ?
>



This does not work today. Errors out

Tue Jun 17 17:15:51 2014 [11884]: Error expecting 'file' but found 'PAM' on
line 7




> Our LDAP password changes frequently as corporate policy. sync up that
> password to /etc/tacacs-passwd would be pain. We have no admin access to
> corporate LDAP to force sync that to /etc/tacacs-passwd.
>
>
>
>
>> 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?
>>
>>
>
>
> --
> 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/edd342d9/attachment.html>


More information about the tac_plus mailing list