[AccessD] Office API's

Drew Wutka DWUTKA at Marlow.com
Tue Dec 14 09:35:37 CST 2010


Jumping in a bit late here, but you don't need to use an API for this.
In fact, the API's I ran into for this had a flaw where they didn't
authenticate users that had non-standard ASCII character codes in their
passwords.  The following routine checks an NT users account name and
password and will work with non-standard ASCII codes too:

Friend Function ValidateNTUser(strUserName As String, strPassword As
String) As Boolean
On Error Resume Next
Dim strDomain As String
Dim conLDAP As ADODB.Connection
Dim strSQL As String
Dim strLDAPConn As String
Dim rsUser As ADODB.Recordset
strDomain = GetObject("LDAP://RootDSE").Get("defaultNamingContext")
Set conLDAP = New ADODB.Connection
conLDAP.Provider = "ADSDSOOBject"
strSQL = "Select AdsPath, cn From 'LDAP://" & strDomain & "' where
objectClass='user' and objectcategory='person' and SamAccountName='" &
strUserName & "'"
conLDAP.Provider = "ADsDSOObject"
conLDAP.Properties("User ID") = strUserName
conLDAP.Properties("Password") = strPassword
conLDAP.Properties("Encrypt Password") = True
conLDAP.Open "DS Query", strUserName, strPassword
Err.Clear
Set rsUser = conLDAP.Execute(strSQL)
ValidateNTUser = False
If Err.Number = 0 Then
    If Not (rsUser Is Nothing) Then
        If Not (rsUser.EOF And rsUser.BOF) Then
                ValidateNTUser = True
        End If
    End If
End If
End Function

Drew

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Heenan,
Lambert
Sent: Tuesday, December 14, 2010 8:25 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Office API's

In actual fact the methods that I have put together that use that
authentication code will allow any other user to enter their own ID and
password on someone else's computer.  The fact that their ID is
different that the one that started the current session is detected, and
code can then take the appropriate action.

So my use of the term "Current Windows Session" was a bit misleading.

Lambert

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav Brock
Sent: Tuesday, December 14, 2010 8:21 AM
To: accessd at databaseadvisors.com
Subject: Re: [AccessD] Office API's

Hi John

OK, that's authentication in general and I understand your purpose. 

My point is that Lambert spoke about the user of the _current_ Windows
session, not "someone" sitting at the keyboard.

/gustav


>>> jwcolby at colbyconsulting.com 14-12-2010 14:00 >>>
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


--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
The information contained in this transmission is intended only for the person or entity 
to which it is addressed and may contain II-VI Proprietary and/or II-VI Business 
Sensitive material. If you are not the intended recipient, please contact the sender 
immediately and destroy the material in its entirety, whether electronic or hard copy. 
You are notified that any review, retransmission, copying, disclosure, dissemination, 
or other use of, or taking of any action in reliance upon this information by persons 
or entities other than the intended recipient is prohibited.





More information about the AccessD mailing list