[tac_plus] user DEFAULT - anyone can login?

[Aaron Wasserott]

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.

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<mailto:vadud3 at gmail.com>> wrote:


On Mon, Jun 16, 2014 at 4:20 PM, Aaron Wasserott <aaron.wasserott at viawest.com<mailto: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<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<mailto: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<http://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<mailto:tac_plus at shrubbery.net>
http://www.shrubbery.net/mailman/listinfo/tac_plus



--
Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu<http://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<http://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/575d9adc/attachment.html>