[AccessD] Office API's

I didn't get that this was going to change the windows logon, but rather test that the user name and 
password are correct and in windows.

John W. Colby
www.ColbyConsulting.com

On 12/14/2010 8:30 AM, Jim Dettman wrote:
>
>   I can see that, but changing a windows logon is going to switch users.  I
> can't see much use for that.
>
> Jim.
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
> Sent: Tuesday, December 14, 2010 08:00 AM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] Office API's
>
> Gustav,
>
> My presentation level security depends on a user logging in as their self so
> that they can have
> access to specific things within the system.  There are cases where a user
> calls a supervisor over
> to do something that requires privileges.  The supervisor logs in as their
> user and performs
> whatever action is necessary and then logs back out.  The normal user logs
> back in.  etc.
>
> Just because a person sits down in a chair and types on the keyboard does
> not mean that person is
> authorized to do something.
>
> John W. Colby
> www.ColbyConsulting.com
>
> On 12/14/2010 3:04 AM, Gustav Brock wrote:
>> But Lambert:
>>
>>> One API that took me so long to find was one that would provide Windows
>>> Authentication. In other words require the user to enter the name and
>>> password that was used to start the current Windows session: to prove
> that
>>> they are who fOsUsername says they are.
>>
>> why would you need to do this? The user has authenticated himself/herself
> when logging successfully in to the current Windows session.
>>
>> /gustav
>>
>>
>>> -----Original Message-----
>>> From: accessd-bounces at databaseadvisors.com
>>> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Heenan,
> Lambert
>>> Sent: Monday, December 13, 2010 11:34 AM
>>> To: Access Developers discussion and problem solving
>>> Subject: Re: [AccessD] Office API's
>>>
>>> One API that took me so long to find was one that would provide Windows
>>> Authentication. In other words require the user to enter the name and
>>> password that was used to start the current Windows session: to prove
> that
>>> they are who fOsUsername says they are.
>>>
>>> Private Declare Function LogonUser Lib "Advapi32" Alias "LogonUserA"
> (ByVal _
>>>      lpszUserName As String, ByVal lpszDomain As String, _
>>>      ByVal lpszPassword As String, ByVal dwLogonType As Long, _
>>>      ByVal dwLogonProvider As Long, phToken As Long) As Long
>>>
>>> Private Declare Function CloseHandle Lib "kernel32" (ByVal hObject As
> Long) As _
>>>      Long
>>> Const LOGON32_PROVIDER_DEFAULT = 0&
>>> Const LOGON32_LOGON_NETWORK = 3&
>>>
>>> ' Check whether a username/password pair is correct'
>>> ' if DOMAIN is omitted, it uses the local account database
>>> ' and then asks trusted domains to search their account databases
>>> ' until it finds the account or the search is exhausted
>>> ' use DOMAIN="." to search only the local account database'
>>> '  IMPORTANT: works only under Windows NT and 2000 and XP
>>>
>>> Private Function CheckWindowsUser(ByVal UserName As String, _
>>>      ByVal Password As String, Optional ByVal Domain As String) As Boolean
>>>      Dim hToken As Long, ret As Long
>>>
>>> ' The handle hToken is not used by CheckWindowsUser ' but is required by
> the API LogonUser
>>>
>>>      ' provide a default for the Domain name
>>>      If Len(Domain) = 0 Then Domain = vbNullString
>>>      ' check the username/password pair
>>>      ' using LOGON32_LOGON_NETWORK delivers the best performance
>>>      ret = LogonUser(UserName, Domain, Password, LOGON32_LOGON_NETWORK, _
>>>          LOGON32_PROVIDER_DEFAULT, hToken)
>>>
>>>      ' a non-zero value means success
>>>      If ret Then
>>>          CheckWindowsUser = True
>>>          CloseHandle hToken
>>>      End If
>>>
>>> End Function
>>>
>>> Lambert
>>
>>