[RADIATOR] Tacacs Authentication to survive reloads ?

[James]

I can't seem to get this working.

I have a few different custom schema attributes in my LDAP database,
namely a description field and a key field.

Here's what my config looks like:

edge-network-device.cfg
-->8--
<ClientListLDAP>
    # how to connect to ldap server
    Host server.whatever.com

    AuthDN cn=anonBind
    AuthPassword none

    BaseDN ou=devices,dc=dhe,dc=duke,dc=edu
    SearchFilter (objectClass=network-device)
    Version 3

    # refresh info from LDAP database every X number of seconds
    RefreshPeriod 5

    # ClientAttrDef parameter allows us to alter the set of LDAP attributes
    # that will be fetched and how they are mapped to <Client> clause
    # parameters
    #
    # this allows us to use the flexibility of an LDAP schema while keeping
    # a basic Radiator configuration
    ClientAttrDef device-type,Identifier
    ClientAttrDef tacacs-key,TACACSPLUSKey
</ClientListLDAP>

--8<--

Since we use different TACACS+ keys for different types of network
devices, it is important that I be able to grab the key for a
particular Client from each LDAP entry.

An attempted connect reveals this in the logs:

-->8--

Fri May 11 14:35:26 2012: DEBUG: New TacacsplusConnection created for
10.41.9.8:43379
Fri May 11 14:35:26 2012: DEBUG: TacacsplusConnection request 192, 1,
1, 0, 99272742, 28
Fri May 11 14:35:26 2012: ERR: Inconsistent lengths in Tacacs
Authentication request from 10.41.9.8:43379. Bad Key?
Fri May 11 14:35:26 2012: DEBUG: TacacsplusConnection Authentication
REPLY 7, 0, Inconsistent lengths,
Fri May 11 14:35:26 2012: DEBUG: TacacsplusConnection disconnected
from 10.41.9.8:43379

--8<--

Any thoughts on how to go about fixing this? I'm sure I'm missing
something obvious.

Thanks!
-james

On Mon, May 7, 2012 at 4:52 AM, Patrik Forsberg
<patrik.forsberg at ip-only.se> wrote:
>> Hello James, Patrik,
>>
>> returning back to this subject after some more investigation, please see
>> below.
>>
>> > Sorry for not chiming in earlier...I'm also dealing with the same
>> > problem -- TACACS+ reload results in dozens of network device
>> > authentications getting lost. I suppose this becomes problematic when
>> > you have a network of my size (2500+ devices).
>>
>> Hmm, since you both need to reload the server, would there be any
>> possibility to do away with this need? You did not tell why you need to
>> restart the server, so maybe this is something that could be changed?
>>
>> > Would it be possible to reinstate functionality that would allow the
>> > TACACS+ server to survive a reload? That would be very, very helpful!
>>
>> I mentioned the AuthorizeGroup changes were the reason for this change,
>> but I was told there are more reasons too, such as response from the
>> original authentication, any related cisco-avpairs and such. So it looks
>> like there is no good way to recover the old functionality.
>>
>> So maybe the need for reloading Radiator could be made less frequent?
>
> Sorry for the late response, been on vacation :), but the issue appears for example when you need to add/remove a client or make any kind of configuration change.
> So even if we do keep the frequency down as much as possible it still annoys the people that need to use the service.
>
> There are a lot of automated systems that do random logins to various systems that use tacacs as authentication method and if for some reason, like adding a new client, it ain't allowed to run its commands it could be devastating to the network(s).
>
> Regards,
> Patrik
>
> _______________________________________________
> radiator mailing list
> radiator at open.com.au
> http://www.open.com.au/mailman/listinfo/radiator