[tac_plus] Problem with creating Multiple groups for a single user. (creating composite groups)

Daniel Schmidt daniel.schmidt at wyo.gov
Tue Apr 8 19:03:31 UTC 2014


Holy #*@&. I'm starting to wish I had programmed inheritance on the groups.
 However, when I first started it, I had NO CLUE that it would ever be
necessary (due to strange different tacacs implementations, NOT a failure
of tac_plus).  It wasn't till later that I even added the ability to change
the tac_pairs.  As it is right now, you'll be in group #^!!:

homer =
     brocade_tier1
     juniper_tier1
     dell_tier1
     no_name_piece_of_junk_ tier1

Now, kudos to Aaron for thinking of an entirely different approach.  Expect
to see his name on tacacs.org,  (At least, I think he'd the first person -
can't remember, anybody else do this?)  Create a teir1.ini and define all
your groups there as ONE access level.  Assign them all to the default
group and do all your assignments in tac_plus.conf like so:

default =
     brocade_tier1
     juniper_tier1
     dell_tier1
     no_name_piece_of_junk_ tier1


Then, in the tac_plus.conf file do all your user assignments, changing only
the "ini" file you use in the after authentication.

# example group with a bunch of seemingly random #*@& you have to do to get
nexus and wlc working
group = tier1_access {
        default service = permit
        service = exec { priv-lvl = 15
                shell:roles="network-operator"
                idletime = 20 }
        # The wlc will not take a return value of 2.  English: those roles
must exist in tac_plus.conf
        service = ciscowlc {
                role1 = MONITOR
        }
        after authorization "/usr/bin/python /root/do_auth.pyo -i $address
-fix_crs_bug -u $user -d $name -l /root/log.txt -f /root/tier1.ini"
}

user = homer {
        member = tier1_access
        service = ciscowlc {
                role1 = ALL
        }
       # optional enable password, if they insist
        enable = file /etc/passwd
}

That there might be your better bet.


On Mon, Apr 7, 2014 at 6:41 PM, Asif Iqbal <vadud3 at gmail.com> wrote:

>
> On Mon, Apr 7, 2014 at 2:24 PM, Daniel Schmidt <daniel.schmidt at wyo.gov>wrote:
>
>> I see no reason why you couldn't do it with one instance with the help of
>> do_auth.  Just need to know what pairs to send to who.
>>
>
> Please let me know if I should start a new discussion thread, but I have
> 13 different tac_plus
> instances with 267 groups and 11969 user = foo {..} entries.
>
> So any user could be on any of those groups as long as no one user in
> multiple groups on any
> of the 13 instances.
>
> I would love to see if I can consolidate all two one instance.
>
> It will probably also help adding a user using a script to multiple
> groups. Currently doing
> tons of awk magics to keep the {} pairs in track while adding new users on
> multiple instances
> into multiple groups.
>
>
>
>
>>
>> On Sun, Apr 6, 2014 at 1:16 PM, Asif Iqbal <vadud3 at gmail.com> wrote:
>>
>>>
>>>
>>>
>>> On Sun, Apr 6, 2014 at 2:53 PM, Daniel Schmidt <daniel.schmidt at wyo.gov>wrote:
>>>
>>>>
>>>> On a side note, while thanking Alan for his assisting while I was out, I
>>>> have to also smile at a bit of irony in that the one person who was wary
>>>> and wouldn't touch do_auth is now helping people with it.  :-P  Thanks
>>>> Alan!
>>>>
>>>
>>> Another offtopic comment, but we manage about 8 different tac_plus
>>> instances
>>> on different IP/PORT combination. And command authorizations are
>>> different,
>>> at least between cisco and juniper. We also have arista, alcatel and
>>> others.
>>>
>>> I should give the do_auth a try, not sure how different command
>>> authorization
>>> syntax can be consolidated?
>>>
>>> Sorry about injecting offtopic conversation here.
>>>
>>>
>>> --
>>> 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?
>>>
>>>
>> E-Mail to and from me, in connection with the transaction
>> of public business, is subject to the Wyoming Public Records
>> Act and may be disclosed to third parties.
>>
>>
>>
>
>
> --
> 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?
>
>


E-Mail to and from me, in connection with the transaction 
of public business, is subject to the Wyoming Public Records 
Act and may be disclosed to third parties.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.shrubbery.net/pipermail/tac_plus/attachments/20140408/6a040f9a/attachment.html>


More information about the tac_plus mailing list