LDAP Timeout

[Hadesis]

Hi,

I'm still working on your tacacs implementation and I'm encountering a problem.

It appear that users get stuck into the login prompt if the LDAP server is unavailable.

I was thinking that the tacacs timeout should be sufficient if configured in the network device, but apparently not...

Is there a way to set a LDAP timeout into your tac_plus implementation ?

Thanks and regards.

--
-=HADESIS=-

Savin Alexis
EPITA 2010 / Responsable LAB TCOM

[Marc Huber]

Hi,

the daemon treads backend failures quite the same as genuine
authentication failures.

I might have misunderstood the problem ... do you want the router to
fall back to local authentication if the LDAP backend fails? Not sure
whether that could be implemented in a sane way. You'd probably be
better of killing the tac_plus daemon if the LDAP server died.

Cheers,

Marc

[Savin Alexis]

Hi,

Well the router doesn't fall back to the local authentication if the tacacs server is still up.

I expected that it would be possible to send the router a timeout if the ldap query failed so that, at least, the authentication would fail. Currently, it's just stuck at the login prompt...

My current solution is as you suggested, to kill the tacacs daemon and restart it using another LDAP server. However, in my opinion, this solution isn't the cleanest one.

Thank you for your answer.

--
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.

[Marc Huber]

According to the tac+ draft:

If the status equals TAC_PLUS_AUTHEN_STATUS_ERROR, then the host is
indicating that it is experiencing an unrecoverable error and the
authentication should proceed as if that host could not be
contacted.

Alas, I'm under the impression that Cisco gear doesn't conform to
that. I've modified the latest snapshot accordingly, but at least my
test router didn't fall back to local authentication. YMMV.

http://www.pro-bono-publico.de/projects/src/DEVEL.201008111908.tar.bz2

(This fixes a potential segfault in the logging code, too.)

If anyone knows of a tac_plus server where local fallback in fact
works (without shutting down the daemon!) I'd be grateful to know.

Cheers,

Marc

On 11 Aug., 11:54, Savin Alexis <alexis.sa...@gmail.com> wrote:
> Hi,
>
> Well the router doesn't fall back to the local authentication if the tacacs
> server is still up.
>
> I expected that it would be possible to send the router a timeout if the
> ldap query failed so that, at least, the authentication would fail.
> Currently, it's just stuck at the login prompt...
>
> My current solution is as you suggested, to kill the tacacs daemon and
> restart it using another LDAP server. However, in my opinion, this solution
> isn't the cleanest one.
>
> Thank you for your answer.
>

> > event-driven-ser...@googlegroups.com<event-driven-servers%2Bunsu...@googlegroups.com>
> > .

[Aleksander Olsen]

Hi Marc

I think this might fall under the same topic, so I'm keeping it in this thread. 

In test, if I deny all traffic from the TAC server to the AD server the fallback does not kick in until the connection attempt to the LDAP times out and gives me this error after about 60 seconds (the fw drops 6 connection attempts):

tac_plus[2528]: 10.10.10.100: shell login for 'aduser' from 10.10.10.5 on tty3 failed (No answer from LDAP backend.)

While this 60 second timer runs and tac tries the ldap the NAS/switch stops all traffic to the tacacs server and falls back to local switch authentication database and I can use that for login.

After 60 seconds I can see the entry in the log and my tacacs fallback accounts work. After the fallback period expires this happens all over again.

Now, I'm sure this is by design or something, but I do have two questions and thus, posting under this thread:

1. Those 60 seconds. Any way to change that to a smaller value in one of the modules?

2. Anyone know why the switch totally stops talking to tacacs for those 60 seconds?`

Keep up the good work by the way. Really appreciate it :-)

Thanks!

Regards

> > event-driven-servers+unsub...@googlegroups.com<event-driven-servers%2Bunsu...@googlegroups.com>

[Aleksander Olsen]

Hi Marc

I think this might fall under the same topic, so keeping it in this thread.

In test, if I deny all traffic from the TAC server to the AD server the fallback does not kick in until the connection attempt to the LDAP times out and gives me this error after about 60 seconds (the fw drops 6 connection attempts):

tac_plus[2528]: 10.10.10.100: shell login for 'aduser' from 10.10.10.5 on tty3 failed (No answer from LDAP backend.)

While this 60 second timer runs and tac tries the ldap the NAS/switch stops all traffic to the tacacs server and falls back to local switch authentication database and I can use that for login.

After 60 seconds I can see the entry in the log and my tacacs fallback accounts work. After the fallback period expires this happens all over again.

Now, I'm sure this is by design or something, but I do have two questions and thus, posting under this thread:

1. Those 60 seconds. Any way to change that to a smaller value in one of the modules?

2. Anyone know why the switch totally stops talking to tacacs for those 60 seconds?`

Thank you very much for any help and keep up the great work on this :-)

Regards,

On Wednesday, August 11, 2010 7:12:31 PM UTC+2, Marc Huber wrote:

> > For more options, visit this group at

>

[Marc Huber]

Hi Aleksander,

On 12.09.13 18:03, Aleksander Olsen wrote:

1. Those 60 seconds. Any way to change that to a smaller value in one of the modules?

in mavis_tacplus_ldap.pl, line 398, try

$ldap = Net::LDAP->new($LDAP_HOSTS, timeout=>5);

The period where fallback users may be used can be set in the configuration file:

authentication fallback period = 60

2. Anyone know why the switch totally stops talking to tacacs for those 60 seconds?

Probably a single-threaded implementation that matches the lack of CPU and RAM.

Cheers,

Marc

[Aleksander Olsen]

Worked like a charm!  The second question just got useless ;)

Thank you!

Regards,

Aleksander