Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com Date: Mon, 14 May 2001 17:41:43 +0400 From: egor duda X-Mailer: The Bat! (v1.45) Personal Reply-To: egor duda Organization: deo X-Priority: 3 (Normal) Message-ID: <72348772478.20010514174143@logos-m.ru> To: Corinna Vinschen Subject: Re: secur32.dll not present on winnt 4.0 sp 5 X-Sender: egor duda Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi! >> there's no secur32.dll on my system. LsaDeregisterLogonProcess() can >> be only found in 'ntoskrnl.exe'. so, Corinna's latest LSA code doesn't > > :-((( > > I have searched for more than an hour to get more information > and it seems you're right. secur32.dll is only available on 9x and > W2K. Interesting enough that Tivoli is using these Lsa functions > as well even on NT4. There must be some other way to get function > pointers to these functions. this functions are not visible in user space. nt uses LPC to communicate to special driver ksecdd.sys, iirc), and it calls appropriate LSA functions. > I just tried a test application which calls LoadLibrary("ntoskrnl.exe") > and then GetProcAddress("LsaLogonUser") which succeeded on both, > NT4 and W2K. Unfortunately, calling that function raises an access > violation. Sure, but nevertheless bad luck. been there, seen that. that's because ntoskrnl.exe is mapped to kernel-space. my LSA efforts year ago stopped right at this point. to call LSA functions on nt 4.0 you should either reverse-engineer LPC interface to ksecdd.sys, or write your own kernel driver and implement your own secure way to communicate with it. both ways is quite problematic. > If somebody could give me a hint how to call the Lsa functions on > NT4, I would be very glad. > >> work. i'm afraid that msdn is wrong stating that >> LsaDeregisterLogonProcess requires NT 3.1 or later. freshly installed >> visual C++ 6.0 sp 3 doesn't have secur32.lib > > Secur32.lib is part of the Platform SDK. > > Sigh. It seems as if I have to dump the subauth DLL and have to > use NTCreateToken instead. This has the advantage that the > complete code could be part of cygwin1.dll instead of requiring > another DLL in /WINNT/system32 but it requires the > SE_CREATE_TOKEN permission. I have just checked that NtCreateToken > is exported by NTDLL.DLL on NT4 and W2K, so at least that should > be no problem... for now, is it possible to conditionalize LSA stuff so that it has been called only if secure32.dll is available? egor. mailto:deo AT logos-m DOT ru icq 5165414 fidonet 2:5020/496.19