Existe uma maneira para o MS Access para pegar a corrente de usuário do Active Directory?
-
08-06-2019 - |
Pergunta
Eu estou trabalhando em uma especificação de um software para minha empresa e como parte do sistema de auditoria acho que seria legal se houvesse uma forma de pegar a corrente de usuário do Active Directory.
Esperemos que algo como:
Dim strUser as String
strUser = ActiveDirectory.User()
MsgBox "Welcome back, " & strUser
Solução
Tente este artigo - Eu tenho algum código no trabalho que irá mtc, o trabalho se este não...
Relevante citar:
Private Declare Function GetUserName Lib "advapi32.dll" Alias "GetUserNameA" _ (ByVal IpBuffer As String, nSize As Long) As Long Private Declare Function GetComputerName Lib "kernel32" Alias "GetComputerNameA" _ (ByVal lpBuffer As String, nSize As Long) As Long Function ThisUserName() As String Dim LngBufLen As Long Dim strUser As String strUser = String$(15, " ") LngBufLen = 15 If GetUserName(strUser, LngBufLen) = 1 Then ThisUserName = Left(strUser, LngBufLen - 1) Else ThisUserName = "Unknown" End If End Function Function ThisComputerID() As String Dim LngBufLen As Long Dim strUser As String strUser = String$(15, " ") LngBufLen = 15 If GetComputerName(strUser, LngBufLen) = 1 Then ThisComputerID = Left(strUser, LngBufLen) Else ThisComputerID = 0 End If End Function
Outras dicas
Aqui está a minha versão:ele vai buscar qualquer coisa que você gosta:
'gets firstname, lastname, fullname or username
Public Function GetUser(Optional whatpart = "username")
Dim returnthis As String
If whatpart = "username" Then GetUser = Environ("USERNAME"): Exit Function
Set objSysInfo = CreateObject("ADSystemInfo")
Set objUser = GetObject("LDAP://" & objSysInfo.USERNAME)
Select Case whatpart
Case "fullname": returnthis = objUser.FullName
Case "firstname", "givenname": returnthis = objUser.givenName
Case "lastname": returnthis = objUser.LastName
Case Else: returnthis = Environ("USERNAME")
End Select
GetUser = returnthis
End Function
Dependendo de variáveis de ambiente para permanecer válido é uma má idéia, já que eles podem ser facilmente alteradas dentro de uma sessão de usuário.
David fez um ponto muito bom, sobre o risco do uso de variáveis de ambiente.Eu só posso acrescentar que pode haver outros problemas com as variáveis de ambiente.Basta olhar para esta real fragmento de código a partir de nossos 5 anos do projeto:
Public Function CurrentWorkbenchUser() As String
' 2004-01-05, YM: Using Application.CurrentUser for identification of
' current user is very problematic (more specifically, extremely
' cumbersome to set up and administer for all users).
' Therefore, as a quick fix, let's use the OS-level user's
' identity instead (NB: the environment variables used below must work fine
' on Windows NT/2000/2003 but may not work on Windows 98/ME)
' CurrentWorkbenchUser = Application.CurrentUser
'
' 2005-06-13, YM: Environment variables do not work in Windows 2003.
' Use Windows Scripting Host (WSH) Networking object instead.
' CurrentWorkbenchUser = Environ("UserDomain") & "\" & Environ("UserName")
'
' 2007-01-23, YM: Somewhere between 2007-01-09 and 2007-01-20,
' the WshNetwork object stopped working on CONTROLLER3.
' We could not find any easy way to fix that.
' At the same time, it turns out that environment variables
' do work on Windows 2003.
' (Apparently, it was some weird configuration problem back in 2005:
' we had only one Windows 2003 computer at that time and it was
' Will's workstation).
'
' In any case, at the time of this writing,
' returning to environment variables
' appears to be the simplest solution to the problem on CONTROLLER3.
' Dim wshn As New WshNetwork
' CurrentWorkbenchUser = wshn.UserDomain & "\" & wshn.UserName
CurrentWorkbenchUser = Environ("USERDOMAIN") & "\" & Environ("USERNAME")
End Function