[tac_plus] user DEFAULT - anyone can login?

[Asif Iqbal]

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