Illegal major version specified: found 39 wanted 192

[Aaron Turner]

I'm trying to authenticate some F5 gear to tac_plus and I'm getting,
"Illegal major version specified: found 39 wanted 192" failures.

Attached is a screen cap of the decrypted tacacs request packet from
the F5 device. Any ideas?

Thanks!

--
Aaron Turner
http://synfin.net/         Twitter: @synfinatic
http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows
Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety.
    -- Benjamin Franklin
"carpe diem quam minimum credula postero"

[Marc Huber]

Hi Aaron,

On 11 Feb., 18:48, Aaron Turner <synfina...@gmail.com> wrote:
> "Illegal major version specified: found 39 wanted 192" failures.

looks like the current implementation handles certain fragmented
packets incorrectly. Does the patch below help?

Thanks,

Marc

--- packet.c 2010/10/31 07:50:18 1.99
+++ packet.c 2011/02/11 19:14:52
@@ -405,7 +405,6 @@
}
if (ctx->hdroff != TAC_PLUS_HDR_SIZE)
return;
- ctx->hdroff = 0;
if ((ctx->hdr.version & TAC_PLUS_MAJOR_VER_MASK) !=
TAC_PLUS_MAJOR_VER) {
report(NULL, LOG_ERR, ~0,
"%s: Illegal major version specified: "

[Aaron Turner]

Thanks Marc. I need to work with the group who manages the F5's to
test this and get back to you.

-Aaron

> --
> You received this message because you are subscribed to the Google Groups "Event-Driven Servers" group.
> To post to this group, send email to event-driv...@googlegroups.com.
> To unsubscribe from this group, send email to event-driven-ser...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/event-driven-servers?hl=en.

[Aaron Turner]

Took a lot longer then I had hoped to test, but that fix solved the
problem I was having with the F5 devices. Thanks Marc!

On a side note, I seem to have noticed a problem that if I have a
tacacsMember attribute for a group that doesn't exist in the
tac_plus.conf, then that user can't seem to login to devices he was
granted access to. Not sure if this is a bug or side effect of a
config option???, but it was pretty confusing when I was debugging it.

[Marc Huber]

Hi Aaron,

On 11 Mrz., 08:07, Aaron Turner <synfina...@gmail.com> wrote:
> Took a lot longer then I had hoped to test, but that fix solved the
> problem I was having with the F5 devices.  Thanks Marc!

thanks for testing :-)

> On a side note, I seem to have noticed a problem that if I have a
> tacacsMember attribute for a group that doesn't exist in the
> tac_plus.conf, then that user can't seem to login to devices he was
> granted access to.  Not sure if this is a bug or side effect of a
> config option???, but it was pretty confusing when I was debugging it.

The daemon handles references to non-existing groups as parse errors
and considers the related user account as invalid. However, parsing
doesn't fail silently. An error message containing both username and
some error text will be logged to syslog:

Mar 11 16:20:08 darwin tac_plus[1548]: Error marc:1: Group
'doesnotexist' not found

I'll see whether the code can be changed to propagate some error
message to the user.

Cheers,

Marc

[Aaron Turner]

That makes a lot of sense when everything is configured statically via
the tac_plus.conf, but when user definitions are in LDAP, the syntax
checking doesn't happen at startup, but rather during authentication.
I would of seen the error message you describe, but the device was
configured to authenticate against one of the other tacacs servers we
have deployed rather then the one I was working on the F5 tests and so
I didn't see the errors.

Honestly, it would be nice if tac_plus just ignored non-existent
groups (other then a warning). The current design seems a bit too
fragile/error prone IMHO and wasn't expected. Of course, if I was
looking at the right server and saw the errors it would of been a lot
easier to diagnose. :)

Thanks,
Aaron

[Marc Huber]

Hi Aaron,

On 11 Mrz., 18:15, Aaron Turner <synfina...@gmail.com> wrote:
> Honestly, it would be nice if tac_plus just ignored non-existent
> groups (other then a warning).  The current design seems a bit too

I don't fully agree with you here. Ignoring configuration errors could
create security issues, this isn't going to happen, even for groups.

I *could* think about implementing some fallback mechanism when doing
group lookups -- return an internal deny-everything group when an
undefined group is referenced. Not sure whether this would be worth
the effort, as this certainly doesn't fix the initial configuration
error.

That being said, today's snapshot (DEVEL.201103121227.tar.bz2)
displays an error message to the user if profile processing failed:

---8<---
> telnet 10.0.0.2
Trying 10.0.0.2...
Connected to 10.0.0.2.
Escape character is '^]'.

Authorized Use Only!

Username: marc
Password:

An error occured while parsing your user profile. Please ask your
TACACS+ administrator to have a look at the TACACS+ logs and provide
the following information:

Host: tacacs.example.com
User: marc
Date: Sat Mar 12 12:37:21 2011

Password incorrect.



Authorized Use Only!

Username:
---8<---


Good enough?

Cheers,

Marc

[Aaron Turner]

On Sat, Mar 12, 2011 at 3:45 AM, Marc Huber <marc.j...@googlemail.com> wrote:
> Hi Aaron,
>
> On 11 Mrz., 18:15, Aaron Turner <synfina...@gmail.com> wrote:
>> Honestly, it would be nice if tac_plus just ignored non-existent
>> groups (other then a warning).  The current design seems a bit too
>
> I don't fully agree with you here. Ignoring configuration errors could
> create security issues, this isn't going to happen, even for groups.

I guess I look at it like Unix groups. If I place a user in a group
which doesn't exist, that user account is not locked out from the
system. That group is ignored and all other groups/acl's are applied
normally. That seems to be the most common result in my experience.

Honestly, I'm not an expert enough in TACACS to know if there is a
situation where a user in a group would have less access then a user
in no groups. If that were true, then you'd be right that the right
thing to do is probably disable the account. What happens when a user
is not in any groups today?

That's very useful and would definitely help a lot and would of
cleared up my confusion a lot quicker.

[Marc Huber]

Hi Aaron,

UNIX groups are additive, while group memberships in tac_plus are
hierarchical and may depend, e.g., on the NAC IP address. In a
configuration such as

user = ... {
...
member = read...@10.0.0.0/8
member = read...@10.1.2.3/24
...
}

simply ignoring the second statement due to some parsing error
obviously wouldn't be a good idea.

If a user isn't in any group then only the definitions and services
directly defined in its user profile will be used.

Cheers,

Marc

[Aaron Turner]

Good point. Thanks!

> --
> You received this message because you are subscribed to the Google Groups "Event-Driven Servers" group.
> To post to this group, send email to event-driv...@googlegroups.com.
> To unsubscribe from this group, send email to event-driven-ser...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/event-driven-servers?hl=en.
>
>

--