VSys One: Volunteer Management Software

Active Directory/LDAP

How does VSys integrate with your Active Directory infrastructure?

• Users (staff, not volunteers) are created in VSys One. These users are then linked to Active Directory accounts rather than given their own user IDs and passwords. (VSys stores the user IDs.)
• When a user signs into VSys, he provides his login ID and password to VSys; VSys then calls Windows to have it authenticate the login information against the current domain. If Active Directory replies (via Windows) that the user and password are valid, and the user in VSys is not disabled, VSys permits the user access.
• Passwords and account disabling are done on the Active Directory side. VSys does not know (or care) what the user's password is, does not enforce complexity, reuse or changing.
• Access/user rights are managed within VSys since they are very specific and granular. Active Directory knows nothing about this.
• VSys does not require any schema changes on the Active Directory side, and it never writes anything to Active Directory - it only queries Active Directory when a user logs in.
• All computers using VSys must be on your domain for the people using them to be able to log in.
• Removing a user from the domain or disabling their Active Directory account effectively locks them out of VSys as well.
• Only a single domain is supported for each VSys One installation.
• Volunteers not using the VSys One desktop application are not "users" in VSys and not subject to its security, nor do they need to exist in Active Directory.

Technical notes

Whenever someone logs into VSys, VSys will take the login credentials it's handed at that moment and authenticate them against AD using LogonUser. It does no impersonation: the user who is currently logged into Windows does not necessarily have any relationship to the user who is logging into the application. (These are usually the same people but VSys does not make that assumption and the rights of the Windows user need not have any relationship to the user who's logging into VSys.)

The call made to LogonUser includes the domain name as a parameter, so even if the user were to manage to take the machine off of the domain then the call would fail, making it impossible for them to establish a local account with the same name as the AD account and bypass the domain account.
LogonUser(UserID, Domain, Password, LOGON32_LOGON_NETWORK, LOGON32_PROVIDER_DEFAULT, token)

LogonUser authenticates to the local machine rather than explicitly calling a remote machine. Here, since the local machine is on the domain (and VSys verifies this before calling LogonUser), the local machine passes the credentials to the domain for it to validate. Using the LOGON32_LOGON_NETWORK option rather than LOGON32_LOGON_INTERACTIVE indicates that the call is being made solely to authenticate the user rather than to log into the local machine as an active user.

"plaintext" in this context (in the MSDN documentation) does not indicate that the user's password is passed in the clear across the network. Here it means that VSys hands LogonUser an unencrypted password rather than a password hash or authentication token because that's what VSys has at the time as provided by the user. If VSys used LOGON32_LOGON_NETWORK_CLEARTEXT then the unencrypted and un-hashed password could be passed across the wire. The way it's being done with LOGON32_LOGON_NETWORK, if you ran WireShark to watch the traffic out of this machine you would not see the password traversing the network as readable text. The MSDN documentation doesn't make it clear but when the Windows machine communicates with its domain controller all of that communication is encrypted.

Required rights

In order for a VSys One user to successfully authenticate using domain authentication, that user must have network login rights to the workstation or server on which VSys is running.