[NoCat] LDAP and NoCat, nearly working..
Jesper Haggren, Zolid
jeha at zolid.dk
Fri May 26 03:57:51 PDT 2006
Hi John,
I'm not about to replace my AD just because of nocat ;-)
Still there's a lot of users on this list who have written about nocat
and MS AD working just fine.... anyone?
/Jesper
John Pugh skrev:
> 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
>
>
> _______________________________________________
> NoCat mailing list
> NoCat at lists.nocat.net
> http://lists.nocat.net/mailman/listinfo/nocat
>
>
More information about the NoCat
mailing list