Debugging Totpcgi and radius
smitch35 opened this issue · 34 comments
I'm running radius in debug mode to watch the totpcgi functions because it's believed that I'm not getting passed the google authenticator accept.
Executing section authorize from file /etc/raddb/sites-enabled/default
+- entering group authorize {…}
++[preprocess] returns ok
++[chap] returns noop
++[mschap] returns noop
++[digest] returns noop
[suffix] Looking up realm for User-Name =
[suffix] No such realm
++[suffix] returns noop
[eap] No EAP-Message, not doing EAP
++[eap] returns noop
[files] users: Matched entry DEFAULT at line 160
++[files] returns ok
rlm_perl: Added pair User-Name =
rlm_perl: Added pair User-Password = 710177
rlm_perl: Added pair NAS-Port = 18120
rlm_perl: Added pair NAS-IP-Address =
rlm_perl: Added pair Message-Authenticator = 0xa58e5a1a0e448959537b04baa83e00fb
rlm_perl: Added pair Auth-Type = Perl
++[perl] returns ok
++[expiration] returns noop
++[logintime] returns noop
[pap] WARNING! No “known good” password found for the user. Authentication may fail because of this.
++[pap] returns noop
Found Auth-Type = Perl
Executing group from file /etc/raddb/sites-enabled/default
+- entering group Perl {…}
rlm_perl: rlm_perl::Detaching. Reloading. Done.
rlm_perl: Added pair User-Name =
rlm_perl: Added pair User-Password = 710177
rlm_perl: Added pair NAS-IP-Address =
rlm_perl: Added pair NAS-Port = 18120
rlm_perl: Added pair Message-Authenticator = 0xa58e5a1a0e448959537b04baa83e00fb
rlm_perl: Added pair Reply-Message = Denied access by rlm_perl authenticate function
rlm_perl: Added pair Auth-Type = Perl
++[perl] returns reject
Failed to authenticate the user.
Using Post-Auth-Type Reject
Executing group from file /etc/raddb/sites-enabled/default
+- entering group REJECT {…}
[attr_filter.access_reject] expand: %{User-Name} ->
attr_filter: Matched entry DEFAULT at line 11
++[attr_filter.access_reject] returns updated
Delaying reject of request 1 for 1 seconds
Going to the next request
Waking up in 0.9 seconds.
Sending delayed reject for request 1
Sending Access-Reject of id 230 to 172.19.4.162 port 41940
Reply-Message = “Denied access by rlm_perl authenticate function”
Waking up in 4.9 seconds.
Cleaning up request 1 ID 230 with timestamp +44
Ready to process requests.
Is the code related to what I'm seeing in radiusd with my personal information removed.
Do you see anything that gives you an idea of what I have configured wrong?
First: do you have totpcgi configured to use pincodes or not? (/etc/totpcgi.conf require_pincode) I can't tell since your scrub completely removed information instead of substituting with something like
Second: "Denied access by rlm_perl authenticate function" is stating that it failed on the check against totpcgi
I would suggest taking a look at your system logs to see what is wrong. totpcgi is very good about telling you the cause of a rejection, just as it's good about stating if the check passed.
For instance here's some excerpts of failures from /var/log/messages
--[cut]--
Jul 8 16:07:26 totp.cgi[14559]: Failure: user=, mode=PAM_SM_AUTH, host=, message=Pincode is required
Jul 8 17:57:20 totp.cgi[17861]: Failure: user=, mode=PAM_SM_AUTH, host=, message=LDAP bind failed: {'desc': 'Invalid credentials'}
Jul 8 17:57:48 totp.cgi[17872]: Failure: user=, mode=PAM_SM_AUTH, host=, message=Not a valid token
Jul 8 17:57:56 totp.cgi[17873]: Failure: user=, mode=PAM_SM_AUTH, host=, message=Token has already been used once
--[/cut]--
And here's what a success should look like:
--[cut]--
Jul 9 15:46:30 totp.cgi[22634]: Success: user=, mode=PAM_SM_AUTH, host=, message=Valid token used
--[/cut]--
then again... it looks like my comments got filtered as well :-/ ok. all those little blanks in my were surrounded by angle brackets... so
Jul 8 16:07:26 [HOST] totp.cgi[14559]: Failure: user=[USER], mode=PAM_SM_AUTH, host=[IP], message=Pincode is required
and such.
Currently it is not configured to use pincodes. Second, it doesn't look like totpcgi is logging to var log messages so it looks like i need to turn it on, which file did i misconfigure there?
Umm... it writes to syslog. I mentioned /var/log/messages as that's where default messages to on a RHEL / CentOS system. If you're using a different OS for this it should be in whatever the default syslog file is.
My /var/log/messages for today only has some info about dhcp and nothing
about my current testing.
On Tue, Jul 9, 2013 at 11:18 AM, Andrew Grimberg
notifications@github.comwrote:
Umm... it writes to syslog. I mentioned /var/log/messages as that's where
default messages to on a RHEL / CentOS system. If you're using a different
OS for this it should be in whatever the default syslog file is.—
Reply to this email directly or view it on GitHubhttps://github.com//issues/16#issuecomment-20686029
.
Sean Mitchuson
System Administrator
Murray State University
Murray, Ky 42071
Phone: 270.809.5756
"MSU Information Systems staff will NEVER ask for your password or other
confidential information via email."
Sounds like you may want to verify that totpcgi is up and running if you aren't getting any logs from it. Do realize that the logs we're talking about are the ones on the totpcgi system if it's separate from your radius system!
That means the radius module isn't even hitting totpcgi, as you can't turn off the logging. I would make sure that mutual SSL authentication is working, since otherwise radius will not be able to reach the CGI.
The guide i'm following leads me to believe that once httpd is running
totpcgi should be running and my page works and i can attach an
authenticator to an account. There are also totpcgi log files in the
/var/log/httpd directory but they don't really seem to have any data in
them.
On Tue, Jul 9, 2013 at 11:23 AM, Konstantin Ryabitsev <
notifications@github.com> wrote:
That means the radius module isn't even hitting totpcgi, as you can't turn
off the logging. I would make sure that mutual SSL authentication is
working, since otherwise radius will not be able to reach the CGI.—
Reply to this email directly or view it on GitHubhttps://github.com//issues/16#issuecomment-20686367
.
Sean Mitchuson
System Administrator
Murray State University
Murray, Ky 42071
Phone: 270.809.5756
"MSU Information Systems staff will NEVER ask for your password or other
confidential information via email."
You can run some tests with the curl command, as described here: https://github.com/mricon/totp-cgi/blob/master/INSTALL.rst#set-up-the-clients
This should let you know if your SSL certificate validation is succeeding or not.
Running that gives me this;
curl: (3) malformed
curl: (35) NSS: client certificate not found (nickname not specified)
which makes me think my certs are wrong.
On Tue, Jul 9, 2013 at 11:48 AM, Konstantin Ryabitsev <
notifications@github.com> wrote:
You can run some tests with the curl command, as described here:
https://github.com/mricon/totp-cgi/blob/master/INSTALL.rst#set-up-the-clientsThis should let you know if your SSL certificate validation is succeeding
or not.—
Reply to this email directly or view it on GitHubhttps://github.com//issues/16#issuecomment-20688182
.
Sean Mitchuson
System Administrator
Murray State University
Murray, Ky 42071
Phone: 270.809.5756
"MSU Information Systems staff will NEVER ask for your password or other
confidential information via email."
I redid my certs and now I get this:
curl: (58) Unable to load client key -8178.
Looks like the guide you're following uses separate cert and key files, so you'll need to pass both --cert and --key. Can you amend your curl call and pass the following additional attribute: --key /etc/pki/tls/certs/totpcgi.key ?
I get
curl: (35) SSL connect error
On Tue, Jul 9, 2013 at 2:02 PM, Konstantin Ryabitsev <
notifications@github.com> wrote:
Looks like the guide you're following uses separate cert and key files, so
you'll need to pass both --cert and --key. Can you amend your curl call and
pass the following additional attribute: --key
/etc/pki/tls/certs/totpcgi.key ?—
Reply to this email directly or view it on GitHubhttps://github.com//issues/16#issuecomment-20697373
.
Sean Mitchuson
System Administrator
Murray State University
Murray, Ky 42071
Phone: 270.809.5756
"MSU Information Systems staff will NEVER ask for your password or other
confidential information via email."
Why don't you hop on #totpcgi channel on freenode IRC. I can help you out faster there.
We got it all sorted it was my fault with a poor edit of the .yaml file. Thanks!
I am also getting:
curl: (35) SSL connect error
Is there a good way to track down what is probably a fat finger mistake?
I also specified the cert and key
matthewjthomas are you following a setup guide (other than our installation document) somewhere for all of this?
I believe I am following the same guide as smitch35 was.
http://vcdxorbust.com/totpcgi-and-freeradius-with-vmware-view/
I have since moved to generating the ca and other certs directly on the box. I ran into an untrusted cert issue. Error 60 but I am going to retry since I may have messed up when making the certs the first time around.
Ah, yes, that does look like the same one. You'll want to grab the latest version of the RADIUS plugin and sample yaml file for use instead of the ones that are in upstream or you could enable the EPEL testing repo and grab the latest release (0.5.5) which will have the updates.
Those make it easier to work with AD and don't require you to go patching things (which was a bit of an issue for smitch35). You'll still need to modify the yaml to point to the correct user object though as it's defaulted to using uid which is for OpenLDAP & FreeIPA.
That being said, I can't remember what the exact issue was for correcting the SSL connect error. We ended up doing an interactive session in #totpcgi on Freenode.
As an aside, if you're doing management of your hosts using puppet, there's a basic puppet module in the contrib directory that will setup the server / client properly using the puppet certificates. Mind you, it's an example module and only sets up sudo escalation to request a token it gets it up and running correctly nice and easy :)
I did the upgrade and when comparing the yaml files I dont see a different. I did change searchbase to userSearchBase a while back when I was troubleshooting. Was that the only change to that file?
So I think I figured out the cert issue.
Now in the curl I am getting:
Username contains invalid characters
Any ideas?
Thanks.
The other change to the yaml was the userAttribute option that was added to get around the patching that folks have been doing on to the perl script for AD.
I'm figuring that the invalid characters statement may be related to the @ you mentioned in your prior ticket. I'm not sure we ever tested against using email style usernames. Can you tighten your checks up to just one OU for now and test against sAMAccountName as I was suggesting in issues #19 at least until you've got it working well from end to end.
If it really is an issue with the @ we may need to open an issue about doing sub OU searches (I haven't looked at that portion of the code) the RADIUS component will handle it fine but I don't know about totp-cgi itself.
If I go back to try and test with sAMAccountName totpcgi gives me a LDAP bind failure error 525 (user not found/invalid credentials)
Is there a different way to add a domain user and test?
I wonder if we can rope in @smitch35 to help out. None of us really run AD, so our experience is very limited.
I tried to use a username based off of the AD field cn but the space in the username was also invalid. Ex. cn=John Smith.
I'm completely stumped on why cn=$username or just $username would work but if I change it to sAMAccountName it fails.
It would be sAMAccountName=$username not just sAMAccountName
Correct, I have also looked at packet dumps and the correct info is coming across. I will look into Active Directory and see if there it is a permission issue.
You might also try connecting to your AD using an LDAP client. Apache Directory Studio (don't use the GSSAPI component for this) is my preferred, but the openldap command line (ldapsearch) would also be a good one to try. You should be able to craft an appropriate LDAP search / bind using one of those it should translate over.
I did a little bit more research on how MAD handles LDAP authentication and it will always try to do one of the following: http://msdn.microsoft.com/en-us/library/cc223499.aspx
From what I can any of these options that would remotely look like a username has either an @ symbol, a \ or a space. All of these show up as special characters when I try to test with curl.
You could try using userPrincipalName as suggested by the article instead of sAMAccountName. In any case, I'm going to have to agree with @mricon on this, I can't be of much more help. I haven't used AD in over 6 years and don't have access to one.
I just tried to do a radtest and I am now getting "Denied access by rlm_perl: account does not pass LDAP user filter" Which was different then before.
/var/log/messages gives this message:
Sep 26 14:50:51 radius01 totp.cgi[7542]: Success: user=jsmith@test.net, mode=PAM_SM_AUTH, host=127.0.0.1, message=Valid token used
Any ideas of where the error may be now?
That tells me that your totp.cgi is passing fine, the problem you're running into will be with either the groupSearch or the search filters not matching the test user.
Again, I suggest you run an LDAP search using the search filter from the totpcgi-handler.yaml and verify that the groupSearch (if there is one) would select the user as well.
I figured it out.I had missed a few variables that needed changing in the totpcgi-handler.yaml.
Thanks for all the help guys. While you guys weren't AD gurus you pointed me in the right direction.
I'm having similar issues, and was wondering if I could also get some help on the Freenode channel or via email?