Smoothwall Authentication

[dhicks]

Hello All,

How do I go about getting Smoothwall to provide un-autheticated users with a given level of access, but if they want to visit certain sites they have to log in as a member of staff / sixth form/ Y11 / etc to a simple HTML login screen with their standard Active Directory username and password? I don't want to use NTLM, that doesn't seem appropriate as we let home users use our network anyway.

--
David Hicks

[tom_newton]

If you use the SSL login page type of auth, that should satisfy part one.. I would say... use "core auth". Then redirect folk yourself to SSL login. "Unauthenticate users" group will then work for those who did not login.

Sorry for dashed off response - bit hectic.

Tom

[dhicks]

If you use the SSL login page type of auth, that should satisfy part one.. I would say... use "core auth". Then redirect folk yourself to SSL login. "Unauthenticate users" group will then work for those who did not login.

Right, I think I've deciphered that: I need to set SmoothWall to use "Core authentication", which puts everyone in to the "Unauthenticated IPs" group unless they explicitally go and log in via SSL. I can get them to log in via SSL by modifying the block page, putting a link to the SSL login page or even a login box for them.

The only minor snag with this plan seems to be that I can't seem to log in via SSL. I've double-checked all the LDAP settings, and the authentication diagnostics screen gives all green lights, but I still always get a failure to log in reported from the SLL login page. Are there some error logs somewhere that I can examine to give me some idea of what the problem might be?

--
David Hicks

[dhicks]

Are there some error logs somewhere that I can examine to give me some idea of what the problem might be?

Ah, what does:

/var/log/authd/debug

do?

--
David Hicks

[tom_newton]

Pass - may not be active on a normal system. There should be some auth logs someplace in the gui (system logs, authd?). HAve you tried logging in as domain\user rather than user?

[dhicks]

There should be some auth logs someplace in the gui (system logs, authd?).

/var/log/messages-2009-12-02 (for today) shows:

Dec  2 17:39:23 s_sys@ACSGATEWAY003 smoothauthd: LDAP user search user=dhicks filter=(userPrincipalName=dhicks) searchbase=ou=AllUsers,dc=convent,dc=altonconvent,dc=org,dc=uk
Dec  2 17:39:23 s_sys@ACSGATEWAY003 smoothauthd: LDAP user search result
Dec  2 17:39:24 s_sys@ACSGATEWAY003 smoothauthd: LDAP user search user=dhicks filter=(userPrincipalName=dhicks) searchbase=ou=AllUsers,dc=convent,dc=altonconvent,dc=org,dc=uk
Dec  2 17:39:24 s_sys@ACSGATEWAY003 smoothauthd: LDAP user search result
Dec  2 17:39:25 s_sys@ACSGATEWAY003 smoothauthd: LDAP user search user=dhicks filter=(userPrincipalName=dhicks) searchbase=ou=AllUsers,dc=convent,dc=altonconvent,dc=org,dc=uk
Dec  2 17:39:25 s_sys@ACSGATEWAY003 smoothauthd: LDAP user search result
[root@ACSGATEWAY003 log]# tail -50 messages-2009-12-02

Which is about the closest I can get to Smoothwall telling me what string it's actually sending to the LDAP (Active Directory) server.

HAve you tried logging in as domain\user rather than user?

Yes, and you get more and more "\" characters each time you press the "Login" button.

--
David Hicks

[DMcCoy]

try ntlm identification instead. If that works then it is the domain join that is broken when DG starts up, this can break for a number of reasons, I've not worked out why it doesn't work on our R2 servers yet. I assume all the auth tests pass?

Dec 2 17:49:49 s_sys@argo smoothauthd LDAP user search user=person@MEDINA.SCHOOL filter=(userPrincipalName=person@MEDINA.SCHOOL) searchbase=ou=Users,ou=Medina,dc=medina,dc=school
Dec 2 17:49:49 s_sys@argo smoothauthd LDAP user search result
Dec 2 17:49:50 s_sys@argo smoothd 6:invoking command loginsslloginuser (10.0.10.19,6,)
Dec 2 17:49:50 s_sys@argo smoothd 6:invoking command loginruleuser (10.0.10.19,6,)
Dec 2 17:49:50 s_sys@argo smoothd Client 6 attempted to invoke unregistered function (loginbridgeuser)
Dec 2 17:49:50 s_sys@argo smoothauthd User person at 10.0.10.19 logged in

Hmm, you seem to be missing the domain suffix in the search

[dhicks]

try ntlm identification instead. If that works then it is the domain join that is broken when DG starts up, this can break for a number of reasons, I've not worked out why it doesn't work on our R2 servers yet. I assume all the auth tests pass?

Yes, all the auth tests give a green light. I'll give NTLM a try tomorrow, see what happens. I don't know what "DG" is, or why it would be trying to join any domain - I've set the LDAP client to do a simple bind, so the client should simply be trying to see if it can connect to the LDAP server with the given username and password.

user=person@MEDINA.SCHOOL ... Hmm, you seem to be missing the domain suffix in the search

Good point, thanks, I'll have a look at that.

--
David Hicks

[DMcCoy]

Yes, all the auth tests give a green light. I'll give NTLM a try tomorrow, see what happens. I don't know what "DG" is, or why it would be trying to join any domain - I've set the LDAP client to do a simple bind, so the client should simply be trying to see if it can connect to the LDAP server with the given username and password.



Good point, thanks, I'll have a look at that.

--
David Hicks

It's either the DansGuardian filter or Squid which joins active directory when using it for authentication. You will see a computer account in AD when it does as this is needed to send kerberos passwords to the server (at least thats my understanding). Identification methods don't need to verify the password so will work fine without the computer account and therefore will work if there are any issues stopping the domain join.

[tom_newton]

@DMcoy - thanks for your help!

If green lights are on with the auth daemon, maybe the user or group search roots are out? I'm out of the office again today (ack!) but RobF is back from doing training, so he may be able to help, or there's always support!

[dhicks]

It's either the DansGuardian filter or Squid which joins active directory when using it for authentication. You will see a computer account in AD when it does as this is needed to send kerberos passwords to the server (at least thats my understanding). Identification methods don't need to verify the password so will work fine without the computer account and therefore will work if there are any issues stopping the domain join.

My new SmoothWall machine (ACSGATEWAY003) isn't joining the Active Directory domain - there's no ACSGATEWAY003 account in the default "Computers" OU in Active Directory. It shouldn't be needing to join, either - LDAP authentication type is set to "simple bind", not Kerebos, and Active Directory is acting as an LDAP server. It should be able to do AD/LDAP authentication exactly the same as with the ldap command-line tools, e.g.:

ldapsearch -h ACSDC001 -D cn=dhicks,ou=AllUsers,dc=convent,dc=altonconvent,d c=org,dc=uk -W ou=UserGroups,dc=convent,dc=altonconvent,dc=org,dc =uk

Switching to NTLM authentication seems to work fine, but then that implies the SmoothWall server is simply getting the username from Windows, not doing any kind of authentication against LDAP.

--
David Hicks

[dhicks]

If green lights are on with the auth daemon, maybe the user or group search roots are out?

A few more steps of LDAP diagnostics might come in handy here - something that lets you check a given user can be authenticated, and gives you diagnostic messages if not.

--
David Hicks

[DMcCoy]

My new SmoothWall machine (ACSGATEWAY003) isn't joining the Active Directory domain - there's no ACSGATEWAY003 account in the default "Computers" OU in Active Directory. It shouldn't be needing to join, either - LDAP authentication type is set to "simple bind", not Kerebos, and Active Directory is acting as an LDAP server. It should be able to do AD/LDAP authentication exactly the same as with the ldap command-line tools, e.g.:

ldapsearch -h ACSDC001 -D cn=dhicks,ou=AllUsers,dc=convent,dc=altonconvent,d c=org,dc=uk -W ou=UserGroups,dc=convent,dc=altonconvent,dc=org,dc =uk

Switching to NTLM authentication seems to work fine, but then that implies the SmoothWall server is simply getting the username from Windows, not doing any kind of authentication against LDAP.

--
David Hicks

I don't believe a simple bind will be sufficient to get windows to verify passwords over ldap with the default domain controller settings. Simple bind will send the password as clear text where AD will usually require the password to be encrypted. You will either need to change the signing requirements on the DCs or pick kerberos on the options in Smoothwall instead.

[plexer]

Make sure the time on your smoothwall is in sync with your dc's

It only needs to join the domain if you do "authentication" i.e NTLM authentication it doesn't need to join for NTLM identification.

You will need to do kerberos authentication.

Make sure your domain is entered in uppercase.

Server username should be specified as user@domain.

Make sure your user search root is high enough for it to find your users.

Ben

[dhicks]

Make sure the time on your smoothwall is in sync with your dc's

Good point - they were actually 15 minutes out, although I don't think that was causing problems. I've set the correct time on the DC now, thanks.

SmoothWall's diagnostic section on the Services >> Authentication >> Control page reads:

Authentication service running RUNNING
Primary LDAP server resolves Open
Secondary LDAP server resolves na
Primary LDAP server connection Open
Secondary LDAP server connection na
Authentication service local connection Open
Authentication service LDAP server connection Open
Can list groups on LDAP server Open

Therefore, I get the impression that SmoothWall can connect to the AD server via LDAP and authenticate the Administrator user to get the list of groups. Therefore, Simple Bind must be working okay. LDAP simple bind also seems to work okay from my own script which I have sitting on another, unrelated, server:

LDAPConnection.simple_bind_s(LDAPDN[0]+form["username"].value+LDAPDN[1], form["password"].value)

Where LDAPDN [0] and [1] equal "cn=" and ",ou=AllUsers,dc=convent,dc=altonconvent,dc=org,dc =uk", respectivly. I don't know exactly, what LDAP string is being passed to the Active Directory server by SmoothWall, I can't seem to find it in any logs.

I have tried Kerberos authentication, too, but have had no better luck. When set to use Kerberos, the "Authentication service LDAP server connection" diagnostic fails. Looking at messages-2009-12-03, I see the last line:

Dec  3 18:56:29 s_sys@ACSGATEWAY003 smoothauthd: GSSAPI Error:  Miscellaneous failure (see text) (unable to find realm of host acsdc001)

Do I need to enable something in Active Directory to turn Kerberos on? Is my Kerberos realm CONVENT.ALTONCONVENT.ORG.UK, the same as the domain name, or something different?

--
David Hicks