Question

I'm working on a spec for a piece of software for my company and as part of the auditing system I think it would be neat if there was a way to grab the current Active Directory user.

Hopefully something like:

Dim strUser as String
strUser = ActiveDirectory.User()
MsgBox "Welcome back, " & strUser
Was it helpful?

Solution

Try this article - I have some code at work that will erm, work if this doesn't...

Relevant quote:

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

OTHER TIPS

Here's my version: it will fetch anything you like:

'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

I got the original idea from Spiceworks.

Depending on environment variables to remain valid is a bad idea, since they can easily be changed within a user session.

David made a very good point about risk of using environment variables. I can only add that there may be other problems with environment variables. Just look at this actual code fragment from our 5-year old project:

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
Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top