¿Existe alguna forma de que MS Access capture al usuario actual de Active Directory?
-
08-06-2019 - |
Pregunta
Estoy trabajando en una especificación para una pieza de software para mi empresa y, como parte del sistema de auditoría, creo que sería genial si hubiera una manera de capturar al usuario actual de Active Directory.
Con suerte, algo como:
Dim strUser as String
strUser = ActiveDirectory.User()
MsgBox "Welcome back, " & strUser
Solución
Prueba este artículo - Tengo un código en funcionamiento que funcionará si esto no funciona...
Cita relevante:
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
Otros consejos
Aquí está mi versión:buscará todo lo que quieras:
'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
Depender de las variables de entorno para seguir siendo válidas es una mala idea, ya que se pueden cambiar fácilmente dentro de una sesión de usuario.
David hizo un muy buen comentario sobre el riesgo de utilizar variables de entorno.Sólo puedo agregar que puede haber otros problemas con las variables de entorno.Basta con mirar este fragmento de código real de nuestro proyecto de hace 5 años:
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