TacacsProfile attribute & login problems
saskiat
Some time before I was looking for fixing password caching problem
with LDAP backend.
You recommended me to fix it with “script out = {if ($RESULT == ACK)
set $PASSWORD_ONESHOT = 1 } ”
In newer version I replace it with parameter “mavis noauthcache”
But I’ve found a problem. If I define in LDAP attribute
“TacacsProfile” value “{ service = shell { default command = deny set
priv-lvl = 15 cmd = show { permit memory permit interfaces
deny .* } } }”
and simultaneously is used “mavis noauthcache”, I have problem with
login. Login works randomly for user with defined this attribute and
value.(first time= ok, second time=fail, third time=ok……)
If I define in LDAP attribute “TacacsProfile” with value “valid until
=….” login works without problems.
Do you have any idea how fix this?
Thanks,
saskiat
Marc Huber
"mavis noauthcache" is global, while PASSWORD_ONESHOT is module
specific. In most cases, there shouldn't be any difference in
behaviour.
For the authentication problem, try either "password = mavis" or apply
the following (untested) patch:
--- tac_plus/mavis.c 2010/09/17 08:19:26 1.71
+++ tac_plus/mavis.c 2010/09/27 14:18:38
@@ -178,6 +178,10 @@
free_user(u);
return;
}
+
+ if ((!u->passwd[PW_LOGIN] && config.pw_login == PW_MAVIS) ||
+ (!u->passwd[PW_PAP] && config.pw_pap == PW_MAVIS))
+ u->embryonic = 1;
}
RB_insert(usertable, u);
Both approaches should work.
Thanks,
Marc
saskia s.
Hi Marc,
Thank you for quick answer.
Both "password = mavis"/patch work.
Thanks,
saskiat
--
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.
saskia s.
Hi Marc,
now I've found another problem with "password = mavis".
If user has defined tacacs_profile like:
{ password = mavis
service = shell {
default command = permit
cmd = show { permit memory permit interfaces deny .* }
}
}
There's no problem with loging (without this parameter it work randomly as described in previos mail).
Problem is, that if I have this parameter enabled, and I change
"cmd"
line (add/remove any command), the old commands are still somewhere in
cache and no changes are reflected. If I remove parameter "password =
mavis" from tacacs_profile, the changes of permited/denied commands are
reflected immediately, but there's back problem with random loginng.
In global configuration I have also enabled "mavis noauthcache".
Thank you for idea.
S.
Marc Huber
you're right, user profiles are held in cache.
Try the patch below. This will remove the old user profile and create
a new one based on the backend TACPROFILE attribute.
Cheers,
Marc
--- tac_plus/mavis.c 2010/09/30 18:15:41 1.73
+++ tac_plus/mavis.c 2010/10/05 15:22:41
@@ -183,14 +183,14 @@
sym.filename = session->username;
sym.line = 1;
- if (!u || !u->embryonic) {
+ s = av_get(avc, AV_A_TACPROFILE);
+ if (s || !u || !u->embryonic) {
rb_node_t *rbn;
if (u && (rbn = RB_search(usertable, u)))
RB_delete(usertable, rbn);
u = new_user(session->username, S_user);
- s = av_get(avc, AV_A_TACPROFILE);
if (s) {
if (parse_user_profile_fmt(&sym, u, "%s", s)) {
free_user(u);
On 5 Okt., 14:40, "saskia s." <sask...@gmail.com> wrote:
> Hi Marc,
>
> now I've found another problem with "password = mavis".
>
> If user has defined tacacs_profile like:
> { password = mavis
> service = shell {
> default command = permit
> set priv-lvl = 15
> cmd = show { permit memory permit interfaces deny .* }
> }
>
> }
>
> There's no problem with loging (without this parameter it work randomly as
> described in previos mail).
>
> Problem is, that if I have this parameter enabled, and I change
> "cmd" line (add/remove any command), the old commands are still somewhere in
> cache and no changes are reflected. If I remove parameter "password = mavis"
> from tacacs_profile, the changes of permited/denied commands are reflected
> immediately, but there's back problem with random loginng.
>
> In global configuration I have also enabled "mavis noauthcache".
>
> Thank you for idea.
>
> S.
>
> > .
saskia s.
Hi Marc,
I've aplied your patch, but there's problem.
Now it has behaviour like "password = mavis"
is not aplied - login works randomly, independantly
if password = mavis is set or not in tacprofile.
Command changes in tacprofile are reflected immediately.
It looks like this patch disables password = mavis option.
Thanks,
saskiat
Marc Huber
all the patch (which will be not included as-in in any snapshot, as I
have some more invasive changes in the queue) does is to remove the
existing profile before adding the one delivered by the backend. Is
"password = mavis" part of the profile data that comes from the
backend, or do you have configured that statically in the
configuration file?
Thanks,
Marc
On 5 Okt., 23:22, "saskia s." <sask...@gmail.com> wrote:
> Hi Marc,
>
> I've aplied your patch, but there's problem.
> Now it has behaviour like "password = mavis"
> is not aplied - login works randomly, independantly
> if password = mavis is set or not in tacprofile.
> Command changes in tacprofile are reflected immediately.
> It looks like this patch disables password = mavis option.
>
> Thanks,
>
> saskiat
>
saskia s.
whole user is defined only in backend,
there's no user definition in configuration file.
So, mavis=password is a part of ldap attribute tacacsProfile.
Cheers,
Saskia
--
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.
Marc Huber
you could try
http://www.pro-bono-publico.de/projects/src/DEVEL.201010071710.tar.bz2
which comes with various password handling and MAVIS related changes.
There shouldn't be any changes in overall behaviour. Notable
exception: "mavis cache timeout = 0" will trigger user lookups for
each TACACS+ session.
I've tested the most common setups, but, as usual, this version isn't
fully regression tested, and feedback is welcome.
(This snapshot isn't linked to from the home page.)
Cheers,
Marc
On 7 Okt., 10:55, "saskia s." <sask...@gmail.com> wrote:
> Hi,
>
> whole user is defined only in backend,
> there's no user definition in configuration file.
> So, mavis=password is a part of ldap attribute tacacsProfile.
> Cheers,
>
> Saskia
>
> > .
saskia s.
I´ve tested it.
1. (one mavis backend)
with "mavis cache timeout = 0" it is not working, switch login prompt writes auth failed.
but tacacs log succeed
26480: 10.0.101.102: shell login for 'saskiat' from 10.0.101.101 on tty1 succeeded
2. (one mavis backend)
with "mavis cache timeout = 1" or higher it is working.
26480: 10.0.101.102: shell login for 'saskiat' from 10.0.101.101 on tty1 succeeded
3. (two mavis backends - auth & authz)
mavis cache timeout = 0 - the same as in 1.
mavis cache timeout = 1 or higher has problem, that after "mavis cache timeout" is reached,
authorization of commands failed and all commands are allowed (tested with value 10)
--
26400: Start authorization request
26400: user 'saskiat': backend failure
--
Before timeout is reached it works as in 2.
saskiat
To unsubscribe from this group, send email to event-driven-ser...@googlegroups.com.
Marc Huber
On 7 Okt., 20:31, "saskia s." <sask...@gmail.com> wrote:
> 26400: Start authorization request
> 26400: user 'saskiat': backend failure
ones that come with the distribution, or custom ones? The behaviour
you're seeing would be typical for a backend script not correctly
processing INFO requests.
Cheers,
Marc
saskia s.
I'm using configuration with 2 mavis backends, one is
mavis_ldap_authonly.pl (for authentication - only user/pass in ldap) and the second
is modified mavis_tacplus_ldap.pl/mavis_tacplus_sql.pl (authorization - doesn't content password)
Configuration is like:
mavis module = external {
exec = /usr/local/lib/mavis/mavis_tacplus_sql.pl (or mavis_tacplus_ldap.pl)
}
mavis module = external {
exec = /usr/local/lib/mavis/mavis_ldap_authonly.pl
}
It looks, that problem exists in mavis_ldap_authonly.pl,
which causes mavis crash (Catched SIGSEGV. Backtrace:...)
and finally backend failure:
mavis_ldap_authonly.pl: 3942: Use of uninitialized value $passwd in string eq at /usr/share/perl5/Net/LDAP.pm line 365, <> chunk 2.
- in INFO packets is not send password on position 8 as in AUTH packets, so probably mavis_ldap_authonly.pl need fix for INFO.
Cheers,
saskiat
--
Marc Huber
On 12 Okt., 18:08, "saskia s." <sask...@gmail.com> wrote:
> mavis_ldap_authonly.pl (for authentication - only user/pass in ldap) and the
> second
it won't honor the TACTYPE attribute. You should either switch to
mavis_tacplus_ldap_authonly.pl or add
script in = { if $TACTYPE == INFO skip }
to the mavis module = external { ... } section.
> It looks, that problem exists in mavis_ldap_authonly.pl,
> which causes mavis crash (Catched SIGSEGV. Backtrace:...)
> and finally backend failure:
care to share the backtrace?
Cheers,
Marc
saskia s.
Hi Marc,
script in = { if $TACTYPE == INFO skip } looks, that
solve the issue with authorization problem (authorization of commands
works also after "mavis cache timeout" is reached)
But now there are 2 problems:
1. The mavis SIGSEGV - what I did, was only login to device and nothing
more - after 49 seconds (usually its about 1 minute) after
authentication was sigsegv&backtrace in syslog
2. If I try to
login again before sigsegv/backtrace is received, I can't { failed (no
such user)}, if I try it after sigsegv, it looks, that tacacs proces is
automaticaly restarted
and login works (but 1. occurs)
Here are syslog messages, my tac_plus.conf and ldif from ldap and sql example for user 'streda'.
Cheers,
saskiat
----------------------------------------------------------------------------
Oct 12 22:30:57 linserver tac_plus[6202]: 10.0.101.102: shell login for 'streda' from 10.0.101.101 on tty1 succeeded
Oct 12 22:30:57 linserver tac_plus[6202]: res = 1
Oct 12 22:31:46 linserver tac_plus[6202]: Catched SIGSEGV. Backtrace:
Oct 12 22:31:46 linserver tac_plus[6202]: 15 [0x804ac11]
Oct 12 22:31:46 linserver tac_plus[6202]: 14 /lib/i686/cmov/libc.so.6(__libc_start_main+0xe5) [0xb7bfc455]
Oct 12 22:31:46 linserver tac_plus[6202]: 13 [0x805a08b]
Oct 12 22:31:46 linserver tac_plus[6202]: 12 /usr/local/lib/libmavis.so(io_main+0x35) [0xb7ea0488]
Oct 12 22:31:46 linserver tac_plus[6202]: 11 /usr/local/lib/libmavis.so(io_sched_exec+0x53) [0xb7ea03c9]
Oct 12 22:31:46 linserver tac_plus[6202]: 10 [0x8059868]
Oct 12 22:31:46 linserver tac_plus[6202]: 9 /usr/local/lib/libmavis.so(RB_delete+0x229) [0xb7e9d3fe]
Oct 12 22:31:46 linserver tac_plus[6202]: 8 [0x805611a]
Oct 12 22:31:46 linserver tac_plus[6202]: 7 /usr/local/lib/libmavis.so(RB_tree_delete+0x2b) [0xb7e9d183]
Oct 12 22:31:46 linserver tac_plus[6202]: 6 /usr/local/lib/libmavis.so [0xb7e9d144]
Oct 12 22:31:46 linserver tac_plus[6202]: 5 [0x8054b43]
Oct 12 22:31:46 linserver tac_plus[6202]: 4 /usr/local/lib/libmavis.so(RB_tree_delete+0x2b) [0xb7e9d183]
Oct 12 22:31:46 linserver tac_plus[6202]: 3 /usr/local/lib/libmavis.so [0xb7e9d144]
Oct 12 22:31:46 linserver tac_plus[6202]: 2 [0x8054b43]
Oct 12 22:31:46 linserver tac_plus[6202]: 1 [0xb7eed40c]
Oct 12 22:31:46 linserver tac_plus[6202]: 0 /usr/local/lib/libmavis.so(catchsegv+0x2d) [0xb7ea9a4e]
---------------------------------------------------------------------------
id = spawnd {
background = no
listen = { port = 49 }
spawn = {
instances min = 1
instances max = 10
}
}
id = tac_plus {
mavis module = external {
exec = /usr/local/bin/mavis_tacplus_sql.pl
}
mavis module = external {
setenv LDAP_SERVER_TYPE = "tacacs_schema"
setenv LDAP_HOSTS = "localhost"
setenv LDAP_BASE = "ou=tacacs,dc=my,dc=domain,dc=tld"
exec = /usr/local/bin/mavis_ldap_authonly.pl
script in = { if $TACTYPE == INFO skip }
}
user backend = mavis
login backend = mavis
mavis noauthcache
mavis cache timeout = 1
host = 0.0.0.0/0 {
key = "foo"
}
--------------------------------------------------------------------------
ldif:
dn: uid=streda,ou=tacacs,dc=my,dc=domain,dc=tld
uid: streda
objectClass: simpleSecurityObject
objectClass: tacacsAccount
objectClass: OpenLDAPperson
cn: streda
sn: streda
userPassword: {CRYPT}4/foo.foo
--------------------------------------------------------------------------
sql:
tcs_uid: streda
tcs_client: 10.0.0.0/8
tcs_profile:
{ password = mavis service = shell { default command = deny set
priv-lvl = 15 cmd = show { permit memory permit interfaces permit
version deny .* } } }
Cheers,
saskiat
Cheers,
Marc
saskia s.
Oct 12 22:33:51 linserver tac_plus[6206]: Version 201010101938 initialized
Oct 12 22:33:51 linserver tac_plus[6206]: epoll event mechanism is being used
Marc Huber
and Darwin work just fine. This happens on a clean install? What OS?
32 or 64bit?
I'd like to have a look at the actual AV pairs set by the backends.
Could you add
mavis module = tee {
path in = /tmp/av.in
path out = /tmp/av.out
}
to your configuration and post the (sanitized) output?
Thanks,
Marc
On 12 Okt., 23:47, "saskia s." <sask...@gmail.com> wrote:
> btw, it was tested with the latest DEVEL.201010101938.tar.bz2 and also after
> tacacs process was restarted, in syslog was logged this:
> Oct 12 22:33:51 linserver tac_plus[6201]: scm_send_msg
> (../spawnd_accepted.c:115): Connection refused
> Oct 12 22:33:51 linserver tac_plus[6206]: Version 201010101938 initialized
> Oct 12 22:33:51 linserver tac_plus[6206]: epoll event mechanism is being
> used
>
>
> >> Hi,
>
> >> On 12 Okt., 18:08, "saskia s." <sask...@gmail.com> wrote:
> >> > mavis_ldap_authonly.pl (for authentication - only user/pass in ldap)
> >> and the
> >> > second
>
> >> mavis_ldap_authonly.pl isn't suitable out-of-the-box for tac_plus, as
> >> it won't honor the TACTYPE attribute. You should either switch to
> >> mavis_tacplus_ldap_authonly.pl or add
>
> >> script in = { if $TACTYPE == INFO skip }
>
> >> to the mavis module = external { ... } section.
>
> >> > It looks, that problem exists in mavis_ldap_authonly.pl,
> >> > which causes mavis crash (Catched SIGSEGV. Backtrace:...)
> >> > and finally backend failure:
>
> >> Shouldn't happen ... I can't seem to reproduce this at the moment,
> >> care to share the backtrace?
>
> >> Cheers,
>
> >> Marc
>
> >> --
> >> 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
> >> .
saskia s.
system is
Debian stable 32bit with security updates in KVM virtual machine.
Linux linserver 2.6.26-2-686 #1 SMP Wed Nov 4 20:45:37 UTC 2009 i686 GNU/Linux
-----
In configuration I've added mavis tee module before external modules.
~5 seconds after login I ran show version and command was executed successufuly and data was logged to to av.in/out file.
To ~60 seconds was logged sigsegv.
av.in:
0 TACPLUS
3 1663745037
4 streda
8 piatok
14 10.0.101.101
21 aI91oz9DUJ4/mf3bv6H+VQ=
25 10.0.101.102
49 AUTH
=
0 TACPLUS
3 1271994664
4 streda
14 10.0.101.101
21 0AHQGt7Z8D3yAPNnduFs/Q=
25 10.0.101.102
49 INFO
=
-----------------------------
av.out:
0 TACPLUS
3 1663745037
4 streda
6 ACK
8 piatok
14 10.0.101.101
21 aI91oz9DUJ4/mf3bv6H+VQ=
25 10.0.101.102
36 piatok
46 10.0.0.0/8
48 { password = mavis service = shell { default command = deny set priv-lvl = 15 cmd = show { permit memory permit interfaces permit version deny .* } } }
49 AUTH
=
0 TACPLUS
3 1271994664
4 streda
6 ACK
14 10.0.101.101
21 0AHQGt7Z8D3yAPNnduFs/Q=
25 10.0.101.102
46 10.0.0.0/8
48 { password = mavis service = shell { default command = deny set priv-lvl = 15 cmd = show { permit memory permit interfaces permit version deny .* } } }
49 INFO
-----------------------------
Oct 13 23:45:33 linserver tac_plus[17546]: startup (version 201010101938)
Oct 13 23:45:33 linserver tac_plus[17546]: epoll event mechanism is being used
Oct 13 23:45:33 linserver tac_plus[17547]: Version 201010101938 initialized
Oct 13 23:45:33 linserver tac_plus[17547]: epoll event mechanism is being used
Oct 13 23:45:39 linserver tac_plus[17547]: 10.0.101.102: shell login for 'streda' from 10.0.101.101 on tty1 succeeded
Oct 13 23:45:39 linserver tac_plus[17547]: res = 1
Oct 13 23:46:33 linserver tac_plus[17547]: Catched SIGSEGV. Backtrace:
Oct 13 23:46:33 linserver tac_plus[17547]: 15 [0x804ac11]
Oct 13 23:46:33 linserver tac_plus[17547]: 14 /lib/i686/cmov/libc.so.6(__libc_start_main+0xe5) [0xb7cdb455]
Oct 13 23:46:33 linserver tac_plus[17547]: 13 [0x805a08b]
Oct 13 23:46:33 linserver tac_plus[17547]: 12 /usr/local/lib/libmavis.so(io_main+0x35) [0xb7f7f488]
Oct 13 23:46:33 linserver tac_plus[17547]: 11 /usr/local/lib/libmavis.so(io_sched_exec+0x53) [0xb7f7f3c9]
Oct 13 23:46:33 linserver tac_plus[17547]: 10 [0x8059868]
Oct 13 23:46:33 linserver tac_plus[17547]: 9 /usr/local/lib/libmavis.so(RB_delete+0x229) [0xb7f7c3fe]
Oct 13 23:46:33 linserver tac_plus[17547]: 8 [0x805611a]
Oct 13 23:46:33 linserver tac_plus[17547]: 7 /usr/local/lib/libmavis.so(RB_tree_delete+0x2b) [0xb7f7c183]
Oct 13 23:46:33 linserver tac_plus[17547]: 6 /usr/local/lib/libmavis.so [0xb7f7c144]
Oct 13 23:46:33 linserver tac_plus[17547]: 5 [0x8054b43]
Oct 13 23:46:33 linserver tac_plus[17547]: 4 /usr/local/lib/libmavis.so(RB_tree_delete+0x2b) [0xb7f7c183]
Oct 13 23:46:33 linserver tac_plus[17547]: 3 /usr/local/lib/libmavis.so [0xb7f7c144]
Oct 13 23:46:33 linserver tac_plus[17547]: 2 [0x8054b43]
Oct 13 23:46:33 linserver tac_plus[17547]: 1 [0xb7fcc40c]
Oct 13 23:46:33 linserver tac_plus[17547]: 0 /usr/local/lib/libmavis.so(catchsegv+0x2d) [0xb7f88a4e]
Oct 13 23:48:19 linserver tac_plus[17546]: scm_send_msg (../spawnd_accepted.c:115): Connection refused
Oct 13 23:48:19 linserver tac_plus[17555]: Version 201010101938 initialized
-----------------------------
Cheers,
saskiat
Marc Huber
I can confirm the crash on a 32bit system. As a temporary workaround
try the patch below. I'm trying to resolve that issue as soon as
possible.
Keep in mind that this patch may introduce a memory leak, so please
consider limiting the number of requests a daemon may process (e.g.
"id = tac_plus { ... retire limit = 1000 ... }").
Thanks,
Marc
--- tac_plus/config.c 2010/10/10 17:38:39 1.640
+++ tac_plus/config.c 2010/10/14 20:04:53
@@ -2612,7 +2612,7 @@
if (!svcp->sub)
svcp->sub = (sym->code == S_shell)
- ? RB_tree_new(compare_cmd, (void (*)(void *)) free_svc)
+ ? RB_tree_new(compare_cmd, /* FIXME (void (*)(void *)) free_svc
*/ NULL)
: RB_tree_new(compare_svc, NULL);
sym_get(sym);
saskia s.
Hi Marc,
looks, that patch works (I've downloaded DEVEL.201010101938.tar.bz2), no sigsegv received.
But there's always problem with login, when I login to device
and do logout immediately and I try to login again (time <60s),
"failed (no such user)". If I try to login again after 60s,
it works...
--
av.in:
= (this is succesfull login)
0 TACPLUS
3 883130525
4 streda
8 piatok
14 10.0.101.101
21 WUIBZiCANAe5DZ89aL5lqg=
25 10.0.101.102
49 AUTH
=(failed, no such user)
0 TACPLUS
3 -1689630805
4 streda
8 piatok
14 10.0.101.101
21 2K6wBbNZTo5V1eKbfDX1bQ=
25 10.0.101.102
49 AUTH
------------------------
av.out:
= (this is succesfull login)
0 TACPLUS
3 883130525
4 streda
6 ACK
8 piatok
14 10.0.101.101
21 WUIBZiCANAe5DZ89aL5lqg=
25 10.0.101.102
36 piatok
46 10.0.0.0/8
48
{ password = mavis service = shell { default command = deny set
priv-lvl = 15 cmd = show { permit memory permit interfaces permit
version deny .* } } }
49 AUTH
= (failed, no such user)
0 TACPLUS
3 -1689630805
4 streda
6 ACK
8 piatok
14 10.0.101.101
21 2K6wBbNZTo5V1eKbfDX1bQ=
25 10.0.101.102
36 piatok
46 10.0.0.0/8
48 { password = mavis service = shell { default command = deny set
priv-lvl = 15 cmd = show { permit memory permit interfaces permit
version deny .* } } }
49 AUTH
Cheers,
saskiat
Marc Huber
can you send me debugging output for that? Needless to say, I don't
see this problem on my machines.
tac_plus = {
...
debug = -1 -PROC -BUFFER
debug redirect = /tmp/tac_plus.debug
...
}
Thanks,
Marc
Marc Huber
apologies ... most of the debug info did probably end up being
syslogged, but wasn't written to the specified file. Please apply
--- tac_plus/report.c 2010/06/28 11:36:27 1.44
+++ tac_plus/report.c 2010/10/16 06:34:49
@@ -69,12 +69,9 @@
va_list ap;
int nlen;
static pid_t pid = 0;
- static int debugtty;
- if (!pid) {
+ if (!pid)
pid = getpid();
- debugtty = isatty(2);
- }
va_start(ap, fmt);
nlen = vsnprintf(msg, len, fmt, ap);
@@ -88,7 +85,7 @@
if ((common_data.debug & level)
|| (session && (session->debug & level))) {
- if (debugtty)
+ if (common_data.debugtty || common_data.debug_redirected)
fprintf(stderr, "%ld: %s\n", (long int) pid, msg);
else
syslog(LOG_DEBUG, "%s%s",
Then "make clean ; ./configure --debug tac_plus ; make ; make install"
and re-run your test.
Thanks,
Marc
On 15 Okt., 22:45, "saskia s." <sask...@gmail.com> wrote:
> Hi Marc,
>
> output is attached.
> I have done 1 successfull login and 2 "unsucessfull" immediately.
> Cheers,
>
> Saskia
>
>
> > Hi Saskia,
>
> > can you send me debugging output for that? Needless to say, I don't
> > see this problem on my machines.
>
> > tac_plus = {
> > ...
> > debug = -1 -PROC -BUFFER
> > debug redirect = /tmp/tac_plus.debug
> > ...
> > }
>
>
>
> 18KAnzeigenHerunterladen
saskia s.
I'm sending you debug again, where you can see 3 login attempts.
first attempt
1. success
->immediatelly after success the next attempt
2. failed
-> ~60seconds after the second failing attempt
3. success
Cheers,
Saskia
Marc Huber
I still can't reproduce that problem, so the following is more or less
based on guessing. Could you please check whether
--- tac_plus/mavis.c 2010/10/12 19:53:18 1.84
+++ tac_plus/mavis.c 2010/10/16 18:44:17
@@ -198,10 +198,13 @@
if (!u
|| (u->dynamic
&& (tacprofile || tacclient || tacmember))) {
- rb_node_t *rbn;
if (config.caching_period) {
- if (u && (rbn = RB_search(usertable, u)))
+ rb_node_t *rbn;
+ tac_user *user = alloca(sizeof(tac_user) + strlen(session-
>username));
+ strcpy(user->name, session->username);
+ rbn = RB_search(usertable, user);
+ if (rbn)
RB_delete(usertable, rbn);
} else {
if (session->user)
changes things to the better?
Thanks,
Marc
> 86KAnzeigenHerunterladen
saskia s.
you're great! It seems that the patch works well!
So, LDAP password changes are reflected immediatelly, repeated login works fine too,
parameter "mavis cache timeout = 0" now works too (before I couldn't login successufully at all, only with =1 and higher),
commands changes in sql also working fine.
I will do some more tests and if I find some problems, I will report it:-)
Could I ask, what was the problem (simple desc) and if this code will be in "official" release?
Thanks,
Saskia
--
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.
Marc Huber
2010/10/16 saskia s. <sas...@gmail.com>:
> Could I ask, what was the problem (simple desc) and if this code will be in
> "official" release?
the lookup_user function honours dynamic user lifetime and returns a
NULL pointer if lifetime is exceeed. The user object, however, then
still exists in the usertable, and needs to be removed before a new
one with the same username can be inserted successfully.
Thanks,
Marc
Marc Huber
Cheers,
Marc
2010/10/17 Marc Huber <marc.j...@googlemail.com>:
saskia s.
Thank you for information.
Btw, it looks, that example in part 4.6.4. CLI Contexts
doesn't work, for example "cmd =~ /^interface FastEthernet 0\/1 /"
crashes on space between "interface" and "FastEthernet".
Cheers,
Saskia
Marc Huber
you actually have PCRE support available on your system?
Cheers,
Marc
On 20 Okt., 15:57, "saskia s." <sask...@gmail.com> wrote:
> Thank you for information.
> Btw, it looks, that example in part 4.6.4. CLI Contexts
> doesn't work, for example "cmd =~ /^interface FastEthernet 0\/1 /"
> crashes on space between "interface" and "FastEthernet".
>
> Cheers,
>
> Saskia
>
>
> > Forgot to mention: Yes, this fix will be part of the next snapshot.
>
> > Cheers,
>
> > Marc
>
> > > Hi Saskia,
>
> > > 2010/10/16 saskia s. <sask...@gmail.com>:
> > in
> > >> "official" release?
>
> > > the lookup_user function honours dynamic user lifetime and returns a
> > > NULL pointer if lifetime is exceeed. The user object, however, then
> > > still exists in the usertable, and needs to be removed before a new
> > > one with the same username can be inserted successfully.
>
> > > Thanks,
>
> > > Marc
>
> > --
> > 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
> > .
saskia s.
as I've written, problem was, that PCRE was not installed.
Now example from doc is loaded, but it looks, that it is not working :(
I did c&p of the example from "CLI Contexts" for user john
(I've changed "password = clear doe" to "login = crypt xxxx" - because
with password line I've always received denied and it was not possible to log-in).
I don't know where's problem, but on Fa0/1 I can't execute shutdown/no shutdown commands.
This is tacacs's debug for commands:
test(config)#interface FastEthernet 0/1
Context has been set. "[no] shut" should work for you.
-
17874: Start authorization request
17874: cfg_get: checking user/group john, tag (NULL)
17874: cfg_get: checking user/group john, tag (NULL)
17874: user 'john' found
17874: cfg_get: checking user/group john, tag (NULL)
##
test(config-if)#shutdown
Command authorization failed.
17874: Start authorization request
17874: cfg_get: checking user/group john, tag (NULL)
17874: cfg_get: checking user/group john, tag (NULL)
17874: user 'john' found
17874: cfg_get: checking user/group john, tag (NULL)
17874: jo...@10.0.101.102: line 103: shutdown: "<cr>" <=> ".": deny
It looks like condition "if (context == FE)" was not matched...
Any idea?
Cheers,
Saskia
Marc Huber
thanks for reporting. Both issues are fixed in todays snapshot.
http://www.pro-bono-publico.de/projects/src/DEVEL.201010252020.tar.bz2
Cheers,
Marc
> It looks like condition "if (context == FE)" was not matched...
>
> Any idea?
>
> Cheers,
>
> Saskia
>
saskia s.
Hi Marc,
hmmm, I have tested this snapshot, but it looks, that the problem still exists (shutdown is denied):
tac_plus version 201010252020/PCRE/DES
---login
24770: Version 201010252020 initialized
24770: cfg_get: checking user/group john, tag (NULL)
24770: cfg_get: checking user/group john, tag (NULL)
24770: cfg_get: checking user/group john, tag (NULL)
24770: cfg_get: checking user/group john, tag (NULL)
24770: cfg_get: checking user/group john, tag (NULL)
24770: 10.0.101.103: shell login for 'john' from 10.0.101.101 on tty1 succeeded
24770: res = 1
24770: cfg_get: checking user/group john, tag (NULL)
24770: Start authorization request
24770: cfg_get: checking user/group john, tag (NULL)
24770: cfg_get: checking user/group john, tag (NULL)
24770: user 'john' found
24770: cfg_get: checking user/group john, tag (NULL)
24770: nas: service=shell (passed thru)
24770: nas: cmd* (passed thru)
24770: nas:absent, server:priv-lvl=15 -> add priv-lvl=15 (k)
24770: added 1 args
---configure terminal
24770: Start authorization request
24770: cfg_get: checking user/group john, tag (NULL)
24770: cfg_get: checking user/group john, tag (NULL)
24770: user 'john' found
24770: cfg_get: checking user/group john, tag (NULL)
24770: jo...@10.0.101.103: configure: default is permit
---interface FastEthernet 0/1 [Context has been set. "[no] shut" should work for you.]
24770: Start authorization request
24770: cfg_get: checking user/group john, tag (NULL)
24770: cfg_get: checking user/group john, tag (NULL)
24770: user 'john' found
24770: cfg_get: checking user/group john, tag (NULL)
---shutdown [Command authorization failed.]
24770: Start authorization request
24770: cfg_get: checking user/group john, tag (NULL)
24770: cfg_get: checking user/group john, tag (NULL)
24770: user 'john' found
24770: cfg_get: checking user/group john, tag (NULL)
24770: jo...@10.0.101.103: line 103: shutdown: "<cr>" <=> ".": deny
Cheers,
Saskia
Marc Huber
is the router configured to use single-connection?
tacacs-server host .... single-connection key ...
Thanks,
Marc
2010/10/26 saskia s. <sas...@gmail.com>:
> --
> 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.
saskia s.
you're right, again :)
Thank you,
Saskia