more than one external mavis authentication module?

[Axel Eble]

Hi Marc,

is it possible to configure two external mavis authentication modules in the tac_plus config so depending on the client one of the two is chosen for authentication? I have a specific client that should authenticate against one AD while all the others should authenticate against a different AD.

Cheers,

Axel

--
Axel Eble, CISSP * Bachgasse 2 * 79108 Freiburg * Germany * cell: +49.178.285-3265

[Marc Huber]

Hi Axel,

you can, albeit somewhat limited, control module behaviour using
scripts. E.g., to skip a particular module for a given user (and try
the next module in the hierarchy):

mavis module = external {
script in = { if ($USER == "johndoe") skip }
setenv LDAP_HOSTS = "dc01"
...
}

mavis module = external {
setenv LDAP_HOSTS = "dc02"
...
}

Cheers,

Marc

[Axel Eble]

On Fri, Aug 6, 2010 at 19:28, Marc Huber <marc.j...@googlemail.com> wrote:

Hi Axel,

you can, albeit somewhat limited, control module behaviour using
scripts. E.g., to skip a particular module for a given user (and try
the next module in the hierarchy):

is it possible to do this for a given client system? something like:

script in = { if ($NAS == "10.1.1.1") skip } 

Doing it user based would require a lot of ifs :)

mavis module = external {
 script in = { if ($USER == "johndoe") skip }
 setenv LDAP_HOSTS = "dc01"

If it's not possible, could I put this as a feature request? :)

Cheers,

[Marc Huber]

Hi Axel,

On 6 Aug., 23:06, Axel Eble <axel.e...@gmail.com> wrote:
> is it possible to do this for a given client system? something like:
>
> script in = { if ($NAS == "10.1.1.1") skip }

you'll need a small patch for that:

*** tac_plus/mavis.c 2010/05/13 07:32:27 1.63
--- tac_plus/mavis.c 2010/08/07 06:15:23
***************
*** 123,128 ****
--- 123,129 ----
av_set(avc, AV_A_USER, session->username);
av_setf(avc, AV_A_TIMESTAMP, "%d", session->session_id);
av_set(avc, AV_A_TACTYPE, type);
+ av_set(avc, AV_A_SERVERIP, session->ctx->NAS_name);
if (session->nac_address_valid)
av_set(avc, AV_A_IPADDR, session->NAC_address);

That should be sufficient to make

script in = { if ($SERVERIP == "10.1.1.1") skip }

work.

Cheers,

Marc

[Marc Huber]

Hi Axel,

forgot one thing: If you have the same user ids on both AD servers you
should add

script out = { if ($RESULT == ACK) set $PASSWORD_ONESHOT = 1 }

to the first module declaration to keep the daemon from caching
passwords.

Cheers,

Marc

[Axel Eble]

On Sun, Aug 8, 2010 at 09:59, Marc Huber <marc.j...@googlemail.com> wrote:

Hi Axel,

Re,

 

forgot one thing: If you have the same user ids on both AD servers you
should add

  script out = { if ($RESULT == ACK) set $PASSWORD_ONESHOT = 1 }

to the first module declaration to keep the daemon from caching
passwords.

Cheers,

Marc

Thanks! The latest snapshot, however, seems to have some problems (or the syntax has changed):

        mavis module = external {

                setenv

/etc/tac_plus/tac_plus.cfg:23: Expected 'return', 'unset', 'goodbye', 'groupid', 'childs', 'separation', 'eval' or 'working', but got 'setenv'

23358: /etc/tac_plus/tac_plus.cfg:23: Expected 'return', 'unset', 'goodbye', 'groupid', 'childs', 'separation', 'eval' or 'working', but got 'setenv'

23358: Detected fatal configuration error. Exiting.

The relevant config part is:

        mavis module = external {

                setenv LDAP_HOSTS = "10.1.1.1:3268 10.1.1.2:3268"

                setenv LDAP_BASE = "dc=domain,dc=tld"

                setenv LDAP_USER = "tac...@domain.tld"

                setenv LDAP_PASSWD = "XXXXXXXXX"

                setenv TACACS_GROUP_PREFIX = "domain_tac_"

                setenv REQUIRE_TACACS_GROUP_PREFIX = 1

                exec = /usr/local/lib/mavis/mavis_tacplus_ads.pl

        }

With a script it barfs at the "script" keyword. Is it a bug or did I miss anything?`

Cheers,

Axel

[Marc Huber]

Hi Axel,

I can't seem to reproduce that issue.

Chances are that the tac_plus binary is using the old libraries. You
did recompile and reinstall?

Cheers,

Marc


On 9 Aug., 15:33, Axel Eble <axel.e...@gmail.com> wrote:

[Axel Eble]

On Mon, Aug 9, 2010 at 18:40, Marc Huber <marc.j...@googlemail.com> wrote:

Hi Axel,

I can't seem to reproduce that issue.

Chances are that the tac_plus binary is using the old libraries. You
did recompile and reinstall?

I didn't reinstall (as I had wanted to check first whether it would parse the (adapted) config file correctly).

So yes, it works. Me dumb (again) ;-)

 

Cheers,

Marc

Thanks!

[Marc Huber]

I'll add a check for library version mismatches to the next snapshot.

Thanks,

Marc


On 9 Aug., 18:59, Axel Eble <axel.e...@gmail.com> wrote:

[Axel Eble]

Hi Marc,

On Sun, Aug 8, 2010 at 09:59, Marc Huber <marc.j...@googlemail.com> wrote:

Hi Axel,

forgot one thing: If you have the same user ids on both AD servers you
should add

  script out = { if ($RESULT == ACK) set $PASSWORD_ONESHOT = 1 }

to the first module declaration to keep the daemon from caching
passwords.

I just got to try this out (needed cooperation for the first AD setting) and it doesn't work (Snapshot DEVEL.201008162038.tar.bz2).

This is the current config:

        # Authentisierung gegen den Corporate Domain Server

        mavis module = external {

                script in =  { if ($SERVERIP != "1.1.1.1" ) skip }

                script out = { if ($RESULT == ACK) set $PASSWORD_ONESHOT = 1 }

                setenv LDAP_HOSTS = "1.1.1.65:3268"

                setenv LDAP_BASE = "dc=corporate,dc=domain"

                setenv LDAP_USER = "tac...@corporate.domain"

                setenv LDAP_PASSWD = "XXXXXXX"

                setenv TACACS_GROUP_PREFIX = "some - other prefix "

                setenv REQUIRE_TACACS_GROUP_PREFIX = 0

                exec = /usr/local/lib/mavis/mavis_tacplus_ads.pl

        }

        # Local AD authentication

        mavis module = external {

                setenv LDAP_HOSTS = "1.2.1.150:3268 1.2.2.150:3268"

                setenv LDAP_BASE = "dc=internal,dc=domain"

                setenv LDAP_USER = "tac...@internal.domain"

                setenv LDAP_PASSWD = "XXXXX"

                setenv TACACS_GROUP_PREFIX = "some_prefix_"

                setenv REQUIRE_TACACS_GROUP_PREFIX = 1

                exec = /usr/local/lib/mavis/mavis_tacplus_ads.pl

        }

 

When I run mavistest against this on the local machine I would expect it to get information from the second external mavis module. Instead, I get nothing:

$ mavistest /tmp/tac_plus-dc.cfg tac_plus TACPLUS axeebl

Input attribute-value-pairs:

TYPE                TACPLUS

TIMESTAMP           mavistest-14363-1282302073-0

USER                axeebl

TACTYPE             INFO

If I comment out the first module declaration I get a reply:

$ mavistest /tmp/tac_plus-dc.cfg tac_plus TACPLUS axeebl

Input attribute-value-pairs:

TYPE                TACPLUS

TIMESTAMP           mavistest-14367-1282302160-0

USER                axeebl

TACTYPE             INFO

Output attribute-value-pairs:

TYPE                TACPLUS

TIMESTAMP           mavistest-14367-1282302160-0

USER                axeebl

RESULT              ACK

SERIAL              MTlp4r+PpapZs3dpMRFW9Q=

TACMEMBER           netadmin

TACTYPE             INFO

If I comment out the second declaration and remove the scripts, it works as well (against the other AD, of course):

$ mavistest /tmp/tac_plus-dc.cfg tac_plus TACPLUS axeebl

Input attribute-value-pairs:

TYPE                TACPLUS

TIMESTAMP           mavistest-14371-1282302262-0

USER                axeebl

TACTYPE             INFO

Output attribute-value-pairs:

TYPE                TACPLUS

TIMESTAMP           mavistest-14371-1282302262-0

USER                axeebl

RESULT              ACK

SERIAL              gFxwjBwjjBMfjDD5m65FGg=

TACMEMBER           Freiburg

TACTYPE             INFO

Same happens (of course) when I just remove the scripts and have both modules declared.

Thanks,

Axel

Cheers,

Marc

On 7 Aug., 08:35, Marc Huber <marc.j.hu...@googlemail.com> wrote:
> Hi Axel,
>
> On 6 Aug., 23:06, Axel Eble <axel.e...@gmail.com> wrote:
>
> > is it possible to do this for a given client system? something like:
>
> > script in = { if ($NAS == "10.1.1.1") skip }
>
> you'll need a small patch for that:
>
> *** tac_plus/mavis.c    2010/05/13 07:32:27     1.63
> --- tac_plus/mavis.c    2010/08/07 06:15:23
> ***************
> *** 123,128 ****
> --- 123,129 ----
>       av_set(avc, AV_A_USER, session->username);
>       av_setf(avc, AV_A_TIMESTAMP, "%d", session->session_id);
>       av_set(avc, AV_A_TACTYPE, type);
> +     av_set(avc, AV_A_SERVERIP, session->ctx->NAS_name);
>       if (session->nac_address_valid)
>         av_set(avc, AV_A_IPADDR, session->NAC_address);
>
> That should be sufficient to make
>
>   script in = { if ($SERVERIP == "10.1.1.1") skip }
>
> work.
>
> 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 event-driven-ser...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/event-driven-servers?hl=en.

[Marc Huber]

Hi Axel,

I'm afraid mavistest is of limited use here -- because it doesn't set
the SERVERIP attribute it won't skip the first module. Only chance to
test this functionality is with a real server (or by modifying
mavistest.c).

Cheers,

Marc

On 20 Aug., 13:07, Axel Eble <axel.e...@gmail.com> wrote:
> Hi Marc,
>

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

[Marc Huber]

Hi Axel,

on second thought, modifying mavistest.c turns out easy enough. The
patch below permits setting attribute-value pairs on the command line:

mavistest -a SERVERIP -v 1.1.1.1 /tmp/tac_plus-dc.cfg tac_plus
TACPLUS axeebl

Cheers,

Marc


--- mavistest.c 2010/08/09 18:06:53 1.19
+++ mavistest.c 2010/08/20 18:57:35
@@ -16,12 +16,13 @@
#include <time.h>
#include <sysexits.h>
#include <errno.h>
+#include <ctype.h>
#include "memops.h"
#include "mavis.h"
#include "version.h"

static const char rcsid[] __attribute__ ((used)) =
- "$Id: mavistest.c,v 1.19 2010/08/09 18:06:53 marc Exp $";
+ "$Id: mavistest.c,v 1.20 2010/08/20 18:57:35 marc Exp marc $";

extern int optind, opterr;
extern char *optarg;
@@ -96,10 +97,12 @@

int main(int argc, char *argv[])
{
- char opt, *optstring = "d:l:tP";
+ char opt, *optstring = "a:v:d:l:tP";
int loop = 1;
int timing = 0;
time_t start;
+ int avt = -1;
+ av_ctx *acd = av_new(NULL, NULL);

init_common_data();

@@ -117,6 +120,15 @@
case 'd':
common_data.debug = atoi(optarg);
break;
+ case 'a':
+ if (isdigit((int) (optarg[0])))
+ avt = atoi(optarg);
+ else
+ avt = av_attribute_to_i(optarg);
+ break;
+ case 'v':
+ av_set(acd, avt, optarg);
+ break;
default:
usage();
}
@@ -138,7 +150,7 @@
start = time(NULL);
while (loop-- > 0) {
av_ctx *ac = av_new(NULL, NULL);
- av_clear(ac);
+ av_copy(ac, acd);

av_setf(ac, AV_A_TIMESTAMP, "mavistest-%d-%ld-%d", (int) getpid(),
(long) time(NULL), loop);


Cheers,

Marc

[Axel Eble]

On Fri, Aug 20, 2010 at 21:03, Marc Huber <marc.j...@googlemail.com> wrote:

Hi Axel,

on second thought, modifying mavistest.c turns out easy enough. The
patch below permits setting attribute-value pairs on the command line:

[…]

Setting the attribute works nicely, thanks. However, same effect - it looks as if it doesn't use the second mavis module at all.

If I set SERVERIP to 1.1.1.1, it authenticates against the corporate DC, in all other cases I get no reply at all. 

Debug output shows:

[…]

Input attribute-value-pairs:

TYPE                TACPLUS

TIMESTAMP           mavistest-20728-1282332478-0

USER                axeebl

SERVERIP            1.2.2.20

TACTYPE             INFO

 20728: + mavis_send

 20728:   av_set(SERIAL) = n+++laFT/IYs6MjbN6IQdw=

 20728:  + external:Mavis_send

 20728:    av_get(SERVERIP) = 1.2.2.20       

 20728:  - mavis_send (16)

 20728:  + mavis_drop

 20728:   + external:Mavis_drop

 20728:     io_unregister 7

 20728:     io_unregister 6

 20728:     io_unregister 9

 20728:    + external:Mavis_drop

 20728:      io_unregister 11

 20728:      io_unregister 10

 20728:      io_unregister 13

 20728:    - external:Mavis_drop

 20728:   - external:Mavis_drop

 20728:  - mavis_drop

Would it be possible to set the environment variables in the script?

script in = { if $SERVERIP = "1.1.1.1" 

setenv …

setenv …

setenv …

else

setenv …

setenv …

setenv …

}

exec = /usr/local/lib/mavis/mavis_tacplus_ads.pl

cheers,

Axel

[Marc Huber]

Hi Axel,

On 20 Aug., 21:30, Axel Eble <axel.e...@gmail.com> wrote:
> Setting the attribute works nicely, thanks. However, same effect - it looks
> as if it doesn't use the second mavis module at all.

my bad ... here's a fix:

--- mavis_glue.c 2010/08/09 18:08:27 1.20
+++ mavis_glue.c 2010/08/22 07:29:49
@@ -117,16 +117,20 @@
if (mcx->script_in) {
switch (mavis_script_eval(mcx, *ac, mcx->script_in)) {
case S_skip:
- return MAVIS_DOWN;
+ break;
case S_return:
if (mcx->script_out)
mavis_script_eval(mcx, *ac, mcx->script_out);
return MAVIS_FINAL;
default:;
+#ifdef HAVE_mavis_send_in
+ result = mavis_send_in(mcx, ac);
+#endif
}
}
#ifdef HAVE_mavis_send_in
- result = mavis_send_in(mcx, ac);
+ else
+ result = mavis_send_in(mcx, ac);
#endif

if (result == MAVIS_DOWN && mcx->down)

> Would it be possible to set the environment variables in the script?
>
> script in = { if $SERVERIP = "1.1.1.1"
>
> setenv …

No, this would involve modifying the environment of an already running
process.

Cheers,

Marc

[Axel Eble]

Thanks, works nicely with mavistest. Going to put it in production :)

On Sun, Aug 22, 2010 at 09:37, Marc Huber <marc.j...@googlemail.com> wrote:

Hi Axel,

On 20 Aug., 21:30, Axel Eble <axel.e...@gmail.com> wrote:
> Setting the attribute works nicely, thanks. However, same effect - it looks
> as if it doesn't use the second mavis module at all.

my bad ... here's a fix:

[...]