This guide discusses how to integrate beSECURE with Active Directory using Windows Server 2012 (earlier and later versions of Windows Server are also supported) and sample usernames. Use the appropriate usernames for your own server.


Setting up the Active Directory server

To set up an Active Directory server to integrate with beSECURE, do the following: 

  1. Set up a Windows Server 2012 Datacenter server.
  2. Sign in to the server.
  3. Open a Powershell prompt, and then enter and run the following command:
    Install-windowsfeature -name AD-Domain-Services –IncludeManagementTools
  4. Enter and run the following commands to create two demo groups:
    New-ADGroup -Name "Accounting" -GroupScope "DomainLocal"
    Press Enter.
    New-ADGroup -Name "IT" -GroupScope "DomainLocal"

    Press Enter.

  5. Enter and run the following commands to create two users:
    Add-ADGroupMember -Identity Accounting -Members "bob.johnson", "mary.smith"
    Press Enter.
    Add-ADGroupMember -Identity IT -Members "mary.smith"
    Press Enter.


Now that the Active Directory server is ready, note the following:

  • When a beSECURE user attempts to sign in to the Active Directory server, they will need to provide the password they were given for the Windows Server (in this case “Pass@word1!”), and then select with Active Directory (instead of Log In).
  • The user's beSECURE username will need to match the Active Directory username (this guide uses “bob.johnson” or “mary.smith”).
  • For security reasons, beSECURE will not look up the requested account in its own database before attempting to sign in to the Active Directory server. Instead, it will attempt to verify the credentials provided with the Active Directory server, and then try to access the account inside beSECURE.
  • The beSECURE account needs to be created before the user attempts to login to the beSECURE server with their Active Directory server credentials.
  • The username created in beSECURE needs to match the “sAMAccountName” in the Active Directory server. To identify a user's "sAMAccountName," use this Powershell script:
    # Function Find Distinguished Name
function find-dn { param([string]$adfindtype, [string]$cName)
# Create A New ADSI Call
$root = [ADSI]''
# Create a New DirectorySearcher Object
$searcher = new-object System.DirectoryServices.DirectorySearcher($root)
# Set the filter to search for a specific CNAME
$searcher.filter = "(&(objectClass=$adfindtype) (CN=$cName))"
# Set results in $adfind variable
$adfind = $searcher.findall()

# If Search has Multiple Answers
if ($adfind.count -gt 1) {
$count = 0
foreach($i in $adfind)
{
# Write Answers On Screen
write-host $count ": " $i.path
$count += 1
}
# Prompt User for Selection
$selection = Read-Host "Please select item: "
# Return the Selection
write-host "sAMAccountName: " $adfind[$selection].Properties["sAMAccountName"]
return "Path: " + $adfind[$selection].path
}
# Return the Answer
write-host "sAMAccountName: " $adfind[0].Properties["sAMAccountName"]
return "Path: " + $adfind[0].path
}
find-dn "user" "Bob Johnson"

    When you run this command, it will return:

    sAMAccountName: bob.johnson
Path: LDAP://CN=Bob Johnson,CN=Users,DC=mycompany,DC=local

    For this guide's example, the user would use bob.johnson to sign in to beSECURE.


Active Directory SSO

The Log in Security" settings in beSECURE are configured as seen in the below:



In the case where the Active Directory server is on the IP address of 192.168.15.132 (you can also use a FQDN DNS hostname), the LDAP Port (389) and the Principal of ‘mycompany.local’ are provided (this is based on the output of LDAP://CN=Bob Johnson,CN=Users,DC=mycompany,DC=local and combining the “DC” values such that it becomes ‘mycompany.local’).


LDAP SSO

Active Directory SSO is the easiest to implement and requires no configuration beyond the Host, Port, and Principal values, but provides very little flexibility with controlling the rights of who can or cannot sign in. A more industry standard method of preforming SSO against an Active Directory server is using an LDAP Proxy account.


Most modern AD LDAP connections stopped supporting anonymous binding (for security reasons), so you will need to create a LDAP Binding account. For security reasons, this account should not be the administrator of your domain, instead, use a user that is part of the Domain Administrator group and is dedicated to the beSECURE binding account. For example, a username called "beSECURE-proxy" has been created in our setup example.


The SSO Filter can be further restricted so that only certain users from a group can sign in to the system. In this example, only users who are members of the "Accounting" group can sign in to the beSECURE system:


When a customer receives the beSECURE setup, it normally includes a virtual machine. There are a few set up options:

  • IS and LSS (beSECUREII)
  • IS (if customer already owns LSS)
  • LSS if the customer would like to deploy a new Scanning Server on his network.