[NoCat] LDAP and NoCat, nearly working..

John Pugh jpugh at jpugh.org
Tue May 23 05:38:19 PDT 2006


On Tue, 2006-05-23 at 10:03 +0200, Jesper Haggren, Zolid wrote:
> Alain,
> 
> Thanks for your reply. After I wrote the list yesterday i switched back to the 0.82 auth-server and actually got it working. Not so
> that users are authorized, but I now get som log-activity on my windows-server.
> 
> The relevant portion of my conf:
> 
> DataSource LDAP
> LDAP_Host        fil-srv2.sgu.dom
> LDAP_Base        ou=sguPublicUsers,ou=SGU,dc=sgu,dc=dom
> LDAP_Admin_User        cn=admin,cn=users,dc=sgu,dc=dom
> LDAP_Admin_PW        pen10u
> LDAP_Hash_Passwords    Yes
> LDAP_Search_as_Admin    Yes
> LDAP_Filter        mail
> 
> 
> I'm using a test user with the logonname "ji", with the domain-name he has a username as so: "ji at sgu.dom". This user is placed in
> the sguPublicUsers OU. When my auth-server contacts the windows-server it generates 5 log-entries, see them below:
> 
> ENTRY 1:
> Logon attempt by:    MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
> Logon account:    admin
> Source Workstation:    FIL-SRV2
> Error Code:    0x0
> 
> (this means that to user (hence admin) was logged on successfully)
> 
> 
> 
> ENTRY 2:
> Logon attempt using explicit credentials:
> Logged on user:
>       User Name:    FIL-SRV2$
>       Domain:        SGU
>       Logon ID:        (0x0,0x3E7)
>       Logon GUID:    -
> User whose credentials were used:
>       Target User Name:    admin
>       Target Domain:    SGU
>       Target Logon GUID: -
> 
> Target Server Name:    localhost
> Target Server Info:    localhost
> Caller Process ID:    860
> Source Network Address:    192.168.1.5
> Source Port:    32804
> 
> (192.168.1.5 is infact my auth-server)
> 
> 
> 
> ENTRY 3:
> Successful Network Logon:
>       User Name:    admin
>       Domain:        SGU
>       Logon ID:        (0x0,0x907B49B)
>       Logon Type:    3
>       Logon Process:    Advapi
>       Authentication Package:    Negotiate
>       Workstation Name:    FIL-SRV2
>       Logon GUID:    -
>       Caller User Name:    FIL-SRV2$
>       Caller Domain:    SGU
>       Caller Logon ID:    (0x0,0x3E7)
>       Caller Process ID: 860
>       Transited Services: -
>       Source Network Address:    192.168.1.5
>       Source Port:    32804
> 
> ENTRY 5:
> 
> (something about what credentials the user (admin) has on the server)
> 
> 
> ENTRY 4:
> User Logoff:
>       User Name:    admin
>       Domain:        SGU
>       Logon ID:        (0x0,0x907B49B)
>       Logon Type:    3
> 
> 
> -----------
> 
> As you see I'm nearly there. But in all 5 entries my user ji at sgu.dom is not mentioned - so something is still wrong. In fact I think
> entry 2 is the problem. The log-entry ID states that it means something like "when a remote users tries to authorize as another user
> (typically when an administrator uses the RUNAS feature on a workstation)". This sounds like a way of doing it.
> 
> Does anyone have a clue?
> 
> /Jesper
> 
> 
> 
> -----Oprindelig meddelelse-----
> Fra: nocat-bounces at lists.nocat.net [mailto:nocat-bounces at lists.nocat.net] På vegne af Alain Fauconnet
> Sendt: 23. maj 2006 03:51
> Til: nocat at lists.nocat.net
> Emne: Re: [NoCat] LDAP and NoCat, nearly working..
> 
> Hello Jesper,
> 
> On Mon, May 22, 2006 at 03:35:29PM +0200, Jesper Haggren, Zolid wrote:
> > Hi NoCat list,
> > 
> > I have a working NoCatAuth setup running with "DataSource = Passwd" - 
> > the last thing I would like to get working is for nocat to use my 
> > existing Windows 2003 Server Active Directory for the authorization part.
> > 
> > I tried both with nocat 0.82 and with the ACTARES-fork. Both 
> > auth-servers are still running. Heres is my senario:
> > 
> > I have a nocat-gateway called gw-srv1:
> > 
> > ETH0, 172.16.1.1: (running DHCP, DNS and so on).
> > ETH1, 192.168.1.3
> > 
> > 
> > Then I have 2 Auth-servers (one with 0.82 and one with the 
> > ACTARES-fork). Currently I use the one with the ACTARES-fork:
> > 
> > ath-srv1, ETH0 192.168.1.4 (ACTARES-fork) ath-srv2, ETH0 192.168.1.5 
> > (0.82)
> > 
> > Both work fine in DataSource=Passwd mode.
> > 
> > Then I have my Windows 2003 Domain controller, fil-srv2 (fil-srv2.sgu.dom):
> > 
> > ETH0, 192.168.1.11 (windows AD).
> > 
> > -----------
> > 
> > The only thing I want is for the AUTH-server to be able to validate a 
> > wireless-user by looking at my Windows AD-server. All users who is 
> > allowed to access the Internet from the wireless network are located 
> > in a OU called "sguPublicUsers".
> > 
> > I have no use for manipulating users/data trough the nocat-admintool. 
> > All user-setup will be done on the Windows server.
> > 
> > I can't get this to work, and the main problem is in fact that I have 
> > no log-file telling me what is wrong - when a user called "ji" tries 
> > to logon using his emailadress (as described in the nocat.conf) which 
> > is ji at sgu.dom (my ad-domain is called sgu.dom) the nocat gateway returns:
> > "That emailadress is unknown. PLease try again".
> > 
> > 
> > All packages should be in place (Net::LDAP and IO::Socket:SSL and so 
> > on..). My authserver nocat.conf file is located below.
> (...rest deleted...)
> 
> I have no direct experience with NoCat using LDAP, but I may need to tackle this soon. Anyway in such a situation my first step
> would be to check if your auth gateway is actually sending LDAP requests or not, and if yes, trace these requests. Check tcpdump or
> much better [t]ethereal, run them on your auth gateway with "host <your LDAP
> server>". Especially [t]ethereal will show you the LDAP
> requests/replies completely decoded. That should hint you.
> 
> Oh wait...  IO::Socket:SSL... of course if all your LDAP traffic goes over SSL this is a dead end. I'm not much familiar with
> Windows AD (I use OpenLDAP) but is there any way to have the LDAP requires go unencrypted during the troubleshooting? If not, ouch.
> Well, at least you can see if there's *any* traffic going on between the two boxes.
> Maybe NoCat isn't even trying to query LDAP.
> 
> Greets,
> _Alain_

The problem is the fact that you are using MS AD which doesn't support
LDAP as the RFC dictates. You are better off using a real directory that
supports LDAP correctly such as Novell's eDirectory or OpenLDAP.

JP




More information about the NoCat mailing list