Authenticating to AD - auth-user-pass-verify not running

tombodet

I didn't want to continue clouding up the original post by adamincanada.

How can I debug this process? I've never run external scripts in openvpn.

I'm seeing "Received AUTH_FAILED control message" at the client.
On the server I'm not sure I'm seeing anything. The log file for the perl script only sees output when I run the script from the command line (which fails), not after an actual auth attempt from a client.

This is on CentOS 5.6 64 bit.

I've got the perl script and config in /etc/openvpn/auth/super_auth_ad.pl (config is ad_super.conf)
In the conf file I've set all the values to my domain, dc, etc.. The only thing I have commented out are the mailto values. In the script I've set $p_conffile to the fully qualified path.

The ovpn server config I added to the end of it:
# Authentication setup
client-cert-not-required
username-as-common-name
auth-user-pass-verify /etc/openvpn/auth/xsuper_auth_ad.pl via-env

From the command line I can do a ping to the dc and get IP resolution. I have a firewall rule for 389 and 636 between the ovpn server and the dc with logging on and there's no traffic. As far as I can tell the script isn't being called. The openvpn.log (level 9) doesn't show a call to the script and there's no direct line that I can tell is the attempt.

This being my first try, I know I'm missing something but I've followed the posted steps. Does the ovpn server need to be in AD and have gone through the kerberos ticket stuff for this to work?

I went for this perl script as it seemed like the easiest option. Maybe there's another one? I'm ultimately going to need to get ovpn to authenticate users to an AD in a secure method (636), including having a user cert. I've already got certs working, it's the AD part I'm hung on.

tombodet

Update: I made a perl script:

#!/usr/local/bin/perl
open (MYFILE, '>>/etc/openvpn/auth/data.txt');
print MYFILE "Bob\n";
close (MYFILE);
exit 0;

Running: perl test.pl at the shell get's me a file output. Using: auth-user-pass-verify /etc/openvpn/auth/test.pl via-env in the ovpn server config then trying a client connection, does not give me the data.txt file output. So ovpn is simply not calling the script.

Anyone?

janjust

make sure

script-security 3

is present in the server config file - otherwise no env vars are passed to the perl script.

increase the verbosity to 5 or higher and reconnect a client - what does the server log now show?

tombodet

janjust wrotemake sure
script-security 3
is present in the server config file - otherwise no env vars are passed to the perl script.

increase the verbosity to 5 or higher and reconnect a client - what does the server log now show?

Thanks for looking in jan. I didn't have a security setting so that fixed the calling of the script.

Security 3 and verb at 5. Found this line in the log:

WARNING: Failed running command (--auth-user-pass-verify): could not execute external program

server config line is:
auth-user-pass-verify /etc/openvpn/auth/test.pl via-env

The init of the service in the log shows it loading the script option:
Fri Aug 5 07:49:42 2011 us=633213 auth_user_pass_verify_script = '/etc/openvpn/auth/test.pl'

From the shell I can run "/etc/openvpn/auth/test.pl" and get output.

ETA: I've set test.pl to public executeable so it shouldn't be a permissions issue.
-rwxrwxrwx 1 root root 172 Aug 5 07:48 test.pl

janjust

as which user does openvpn run? is the script executable by that user (e.g. 'nobody' or 'openvpn') ? can you replace the script by a dumym script and see if *that* works?

tombodet

I've never been good at remembering to install things as non-root. Once I'm done with this test I have to fix that.

So in other words, ovpn was configured and installed as root.

The script I'm pointing the server.conf at right now I'd say IS a dummy script:

#!/usr/bin/perl
open (MYFILE, '>>/etc/openvpn/auth/data.txt');
print MYFILE "Bob\n";
close (MYFILE);
exit 0;

Again, from the shell I can run "/etc/openvpn/auth/test.pl" and get output, meaning a new file called data.txt shows up and it contains "Bob". I delete that file, restart ovpn, try a client login and then get the error about not being able to execute the external program.

The test script is world read/write/executable.

janjust

what about the directory

/etc/openvpn/auth/

? is it accessible (755) ?

you've written a nice dummy script, but try to NOT write stuff to a file, but simple do

#!/usr/bin/perl
print "Bob\n";
exit 0;

run openvpn in non-daemon mode (i.e. don't use 'daemon' or 'log' or 'log-append') but just make sure openvpn logs everything to stdout/stderr; now connect a client; on the server console screen you should see the output of the script (if it runs successfully).

You can also try using

script-security 3 system

which makes your openvpn even less secure but it will use 'system' calls to launch your script - if that works then we have to figure out why it does not work without 'system'

tombodet

Damn, wouldn't you know it, I thought about directory permissions late last night.

I used the writing to a file because I wasn't sure how to to know the script actually ran without some form of traceable output.

Directory perms was it, script is running successfully and the fake positive return allows the client to connect. Now to move on to the real auth script. We'll see how badly I do on this one.

tombodet

UPDATE:

Ok, after I set write and execute permissions for everyone on the files involved it's running the auth script and logging it. yay.

This leaves me with 2 problems that I'm now beyond what I've ever had to configure.

First is permissions. In the ovpn conf, user/group is currently set to nobody. Looking at the docs, this is literally the user/group that the service will operate under, correct?

This system was set up based on the NIST guidelines so things are a little tighter than normal. What I'm wondering is the best way to do the script and logging. Set the user to an unprivileged account and stick it all in his home dir so it has read/write/ex permission? The public setting in /etc isn't going to fly.

Second issue. Using the auth script tacked here, this is the error:
2011-08-09 14:25:16 [ERR_AUTH] authentication failure; user: user1; from: xxx.xxx.xxx.xxx(1058/); details: Cannot find KDC for requested realm (0x9a); time: 1969-12-31 19:00:00

janjust

First is permissions. In the ovpn conf, user/group is currently set to nobody. Looking at the docs, this is literally the user/group that the service will operate under, correct?

correct - this was why I asked under which user openvpn was running (not installed) ; after starting up openvpn switches to userid+groupid nobody and only files and directories readable and writeable for that user can be used.

2011-08-09 14:25:16 [ERR_AUTH] authentication failure; user: user1; from: xxx.xxx.xxx.xxx(1058/); details: Cannot find KDC for requested realm (0x9a); time: 1969-12-31 19:00:00

I'm not too familiar with this Active Directory script but this looks like the script cannot contact the Kerberos Domain Controller (KDC) ; AD is a modified version of Kerberos, so it looks like the script is unable to authenticate with the AD controller.

tombodet

OK, I'd like to keep this going, sorry I disappeared, I had to stand up an FTP server with last minute notice.

I got kerberos connected and am authenticating against the domain, had a typo in the krb5.conf.

The thing I'm trying to iron out now is the use of username-as-common-name.

From reading the description, I figured that if I didn't enable that, it would use the name on the cert. However using user1's cert on a client and connecting with user2's password got me in. The vpn log shows my cert name but the AD log shows the user name I entered in. The user's passwords are not the same just to be sure of what's going on.

Am I missing something again or is it not possible? What I'm trying to do is restrict the connection to only allow the user that the cert is for. In other words, don't let user2 log in with his creds on user1's certificate.

tombodet

I found a way to do it via script I think. This appears to be working: Edit the perl script under the do_script section:

 # Authentication script
    elsif ($ENV{"script_type"} eq "user-pass-verify") {
        # Authenticate the user (this function will not return if it fails)
        # switched common_name (from cert) for username (from user filled in name)
        #authenticate($ENV{"username"},$ENV{"password"});
        authenticate($ENV{"common_name"},$ENV{"password"});

        # Authorize the user (this function will not return if it fails)
        # switched common_name (from cert) for username (from user filled in name)
        #authorize($ENV{"username"},$ENV{"password"});
        authorize($ENV{"common_name"},$ENV{"password"});

        # If we're still here, return a success value
        exit 0;
    }

Passing the common_name to the authenticate and authorize functions forces the issue. I've been able to type anything into the username field at the client end and it's authenticating to the user in the cert.

I'll stick with this unless there's another way to do it via ovpn's config.

janjust

The thing I'm trying to iron out now is the use of username-as-common-name.

the option 'username-as-common-name' is a nifty trick that is used only when you're connecting using 'auth-user-pass' ; it is used *AFTER* the auth-user-pass-verify script has succeeded and it is used in the scripts/plugins that are called afterwards, such as 'client-connect', 'client-disconnect', 'learn-address' etc.