Introducing Novell Identity Manager Google Apps Driver Part 2



By: daredl2

April 18, 2011 12:23 am

Reads: 327

Comments:1

Rating:0

Introducing the Novell Identity Manager Google Apps Driver – Part 2

In the first article of this series Introducing the Novell Identity Manager Google Apps Driver – Part 1 I introduced the new driver and some of the features. In this article I will go into more in-depth with the objects that are supported by the driver starting with the User object.

The user object in eDirectory is mapped to the UserEntry object in Google. Google uses different API’s for different features related to users. The Provisioning API is responsible for creating the Google Apps account, password, Given Name, First Name, Login Disabled, and Nick Name.

The profile API is responsible for the information that is found in the Google Contact application (Address Book). The driver supports over 20 of these attributes including department, phone number, mobile phone number, title, and location. The profile API is similar to the shared contact API in attributes only. The contact API will be discussed in a future article. Google has a very interesting quirk with the information passed to these API’s. Any new user that is created via the Google control panel or from the API will not show up in Google Contacts (Address Book) for 24 hours even though the information is there and can be queried for immediately after creation. When testing the driver please be aware of this. Once the initial 24 hour period is complete the changes will show as soon as the driver processes the modify.

The driver also supports attributes that affect the users email account via the email API. These attributes include the GmailSettings attributes included with the drivers schema. The driver documentation includes sample settings on how to set these values on your User accounts. In most cases these attributes are not necessary. However if you have multiple email domains or unique email requirements these attributes may be necessary.

The following list details a few of the most commonly used attributes with the email api:

  • GmailSettingsSendAs – This structured attribute will set the default send-as email address and name. For instance if my user name is ddare and I also have a nickname of Don.DaRe I can use this attribute to set the default Send-As address to Don.DaRe. This would allow me to logon with ddare and my primary email address to be Don.DaRe@domainname.com
  • GmailSettingsForwarding – Setting this structured attribute allows email sent to the user account to be forwarded automatically to another account. The email address must be in the same domain. The driver is unable to set a value outside of the users email domain. If an address is set outside of the domain it will be rejected by the Google API (You can see this in the driver trace. The API will ask for a captcha to be processed which is impossible for the driver to do.).

All of the Identity Management events (Add, Modify, Delete, Rename, Move and Query) are supported on this object. The default driver packages include policies for account entitlements as well as a framework for multiple email domain support. I will dedicate an entire article for setting the driver up to work with multiple email domains. Here is a breakdown of all the events.

  • Add events are straight forward. The default set of policies will take the eDirectory username and create an account in Google Apps. Google does require a password on an Add event so a sample policy is included to automatically generate a password if none is available. Placement is either flat or mirrored.

  • Modify events have no special use cases. Please see the documentation for modification of some of the special attributes.
  • Delete events have a serious side effect within Google. The first is that when a user is deleted they can not be created again within 5 days. The driver is configured to rename the user object prior to deletion. Once a user has been deleted all of the documents a user is the owner of are lost after 5 days. Use extreme caution when deleting user accounts.
  • Rename events will cause the driver to rename the Google UserEntry and thus the users primary email address to be changed. The old value will be stored as a NickName within Google Apps. If you wish to change this behavior you will need to write a policy to handle this after the rename occurs. Please note that when a rename event comes through the driver it will automatically modify the users association as the association contains the user name.
  • Move events can be performed if you are using the mirrored configuration and you have deployed organization objects within Google Apps. This is an intensive operation within Google Apps and can take up to an entire minute to move an object. In large deployments of several thousand accounts or higher you should be cautious in your setup.
  • Query is supported.

Placement of users is either flat or mirrored. It is possible to write entitlements for user placement if you require it. It is important to note that when placing a user in Google Apps that the DN not contain a leading ‘\’ like we do with other drivers. We will discuss Organizations in a future article as well.

In the next article we will discuss group management with the driver.

The driver has officially shipped on April 15th and is included with the standard and advanced editions of Identity Manager 4.0.1.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Categories: Uncategorized

Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment.  It just worked for at least one person, and perhaps it will be useful for you too.  Be sure to test in a non-production environment.

1 Comment

  1. By:wightmanpete

    Hello there

    This version of NIM with the Google Apps driver seems to be perfect for a project I have in mind.

    There is an unofficial application, GAM, that has the capability to perform this, albeit from the command line (not so scary to old school sysadmins like me)…

    The scenario

    Google Apps Domain – acme.com
    Google Apps Secondary domain new.acme.com
    Google Apps Secondary domain old.acme.com

    Can a user, pete@old.acme.com be renamed/moved by NIM to pete@new.acme.com ?

Comment