Howtos/AD Integration

Extending the Schema

The schema is what describes the attributes that Active Directory can use. It contains information such as attribute name, attribute size or length, data type, and relationship to other attributes. The schema must be extended to also include Scalix attributes such as mailnode, account type (premium or standard), and so on.

Extending the Schema is documented in the Scalix Setup and Configuration Guide, Integrating with Active Directory, Installing the Schema Extensions.

Extending the GUI

The GUI is the user interface used to administer users in Active Directory. It is called "Active Directory Users and Computers," or ADUC. After the GUI is extended, you will have two new tabs in the User Properties or Group Properties window, where you can add or modify Scalix attributes.

Extending the Schema is documented in the Scalix Setup and Configuration Guide, Integrating with Active Directory, Installing the GUI Extensions.

Updating Existing Entries

Generally speaking, if you have made the decision to integrate Scalix with Active Directory, you already have Active Directory installed and you are already administering user and group records in AD. The existing AD entries must be modified so that Scalix will import them and have the necessary data to administer the Scalix accounts. The section #Updating Active Directory Entries explains how to do this.

Frequently, you will have Scalix in full production and you'll need to modify the Scalix user data so that Scalix knows the user entries are "owned" by Active Directory. The section #Updating Scalix Entries will explain how to do this.

Updating Active Directory Entries

There are three Scalix attributes which must be populated in order for Scalix to be able to import and use the record. These attributes are scalixScalixObject, scalixMailnode, and scalixMailboxClass.

• scalixAdministrator - set to 'TRUE' if the user will have administration privileges on the Scalix server.
• scalixHideUserEntry - set to 'TRUE' if the user's information will be hidden from the email clients' address books.
• scalixLimitMailboxSize - set to the maximum size, in MB, that the user account can be.
• scalixLimitOutboundMail - set to 'TRUE' if the user will not be allowed to send messages when over quota.
• scalixLimitInboundMail - set to 'TRUE' if the user will not be allowed to receive new messages when over quota.
• scalixLimitNotifyUser - set to 'TRUE' if the system should send the user an email letting him know when he's over quota.
• scalixMailboxAdministrator - set to 'TRUE' if the user will have mailbox administration privileges on the Scalix server.
• scalixMailboxClass - set to 'FULL' for a premium account or 'LIMITED' for a standard account.
• scalixMailnode - the mailnode with which the account will be associated. Usually this is the default mailnode (run 'omshowmn' on the Scalix server; default mailnode will have two asterisks beside it).
• scalixScalixObject - set to TRUE if the entry is to be imported into Scalix. You can set this to TRUE by modifying the contents of the AD entry, or by right-clicking the user name and then "Create Scalix Mailbox," or by checking the box "Create Scalix Mailbox" when you're first creating an ADUC user or group.
• scalixServerLanguage - defaults to 'C' but can be set to other values.

Updating AD Entries Manually

If you have only a few entries in Active Directory that correspond to Scalix accounts (either already created or to be created via omldapsync) you can edit the entries manually. Simply go into ADUC, right-click the user's name, select "Create Scalix Mailbox" and enter the relevant data in the wizard. The act of creating a Scalix mailbox will set scalixSalixObject to TRUE. The only other attributes you have to fill in are mailnode and mailbox class.

Updating AD Entries with a Script

If you have several hundred entries, you will find it more convenient to script the changes. Below is a sample script but it is provided simply as a guideline. It is not warranted in any way. It is meant to be saved and run on the AD domain controller. Use at your own risk.

ModUsers.swf:

<job>
<script language="VBScript">

Option Explicit
On Error Resume Next
Dim objConn, objComm, objRS, objUser
Dim strBase, strFilter, strAttrs, strScope

strBase = "<LDAP://dc=mydomain,dc=net>;"
strFilter = "(&(objectclass=user)(objectcategory=person));"
strAttrs = "ADsPath;"
strScope = "Subtree"

Set objConn = CreateObject("ADODB.Connection")
objConn.Provider = "ADsDSOObject"
objConn.Open

Set objComm = CreateObject("ADODB.Command")
Set objComm.ActiveConnection = objConn
objComm.CommandText = strBase & strFilter & strAttrs & strScope
objComm.Properties("Page Size") = 1000
Set objRS = objComm.Execute()

While not objRS.EOF
  Set objUser = GetObject( objRS.Fields.Item("ADsPath").Value )
  objUser.scalixScalixObject = "TRUE"
  objUser.scalixMailboxClass = "FULL"
  objuser.scalixMailnode = "sxlab"
  objUser.SetInfo
  if Err.Number <> 0 Then
    Wscript.Echo objUser.Name & " error occurred"
    Err.Clear
  Else
    Wscript.Echo objUser.Name & " modified"
  End if
  objRS.MoveNext
Wend

</script>
</job>

The above will turn all AD users in to Scalix users so you'll need to go back and manually undo some of the ADUC users like ISUR_EXLAB and IWAM_EXLAB. Or perhaps modify the script so it doesn't affect ADUC users with a description containing the string "Built-in account".

Updating Scalix Entries

Scalix user accounts that have already been created via SAC, but which you now want to administer from AD, need to be modified so that their Global-Unique-ID matches the objectGUID in Active Directory. You can do this via any method you like; below are a command to retrieve the users and their objectGUID values from AD, and then an awk script to build a series of ommodent commands for each of those users.

First, get a list of all Scalix users from Active Directory, along with their objectGUID values, in LDIF format:

# omldapsearch -D "cn=Administrator,cn=Users,dc=mydomain,dc=net" -w secret -h adhost.mydomain.net -b dc=mydomain,dc=net scalixScalixObject=TRUE -L "" cn objectGUID > /file.ldif

You will, of course, need to modify that command to reflect your own domain, AD user and password, search base, etc.

The following awk script will help you build a series of commands to modify the global-unique-id of all your Scalix users so they match the AD objectGUID. This isn't anything officially developed and supported by Scalix, it's just here as a convenience and to give you one way to do it. You have to change two entries: the default SYSTEM directory, which is used by many email clients as the "address book", and the hidden USERLIST directory which is vaguely similar to /etc/passwd in that it contains information about the user's account location, etc.

# changeuid.awk
# Used to change Scalix global-unique-id to same value as Active Directory
# objectGUID.  Requires ldif input that contains at least cn and objectGUID 
# values
# usage:  awk -f changeuid.awk file.ldif | sed -e 's/cn= \" /cn=\"/; s/id=" /id="/g'  > /tmp/update

BEGIN { FS = ":" }

/^cn:/  { 
  name=$2 
  next
}

/^objectGUID:/ { 
  UID=$3 

  if ( name != "" && UID != "" ) {
    printf "ommodent -e cn= \"%s\" -n global-unique-id=\"%s\"\n", name, UID 
    printf "ommodent -e cn= \"%s\" -n global-unique-id=\"%s\" -d userlist -t h\n", name, UID 
    name=""
    UID=""
  }
}

After running the above script, you'll still need to edit the output file a bit. You'll need to escape special characters such as / and ==

vi /tmp/update
:%s/==/\\=\\=/g
:%s/\//\\\//g
:wq

Run the script

# sh /tmp/update

Watch for errors. Users that are in AD but not in Scalix will give "entry not in the directory" errors; that's okay, they'll get imported later.

Also, if you see any GUIDs that are shorter than the others or that do not end in ==, then that GUID did not get retrieved correctly via the omldapsearch. Sometimes that happens; I'm not sure if the problem is in the way omldapsearch retrieves or displays the value, or in the way AD delivers the data in response to the search command. If you're bored you could play with it and find out :) At any rate, there won't be many and it's easy to correct later. When you run omldapsync you'll see errors in the sync.log file saying "Failed to locate or retrieve information in LDAP for id 0TWh88zLEkWmrRRtw9kyqA==" in the SOAP response. Look above the SOAP response to the SOAP Request and you'll see the user (or group) that is generating the error. Simply ommodent their global-unique-id in the SYSTEM and USERLIST directories to match what is shown in the error (remembering to escape == and / and put it all in quotes).