In part one of this series I walked through some of the configuration, Packages, and GCVs used in the Office 365 IDM driver.

In part two of this series I walked through more of the GCVs and looked at some possible values for the License entitlements.

In part three of this series I looked at the Filter and Schema Map and some more entitlement issues.

In part four of this series I looked at the configuration settings and then on to actual policies, getting through the Subscriber Event Transform policy set.

In part five of this series I worked through the Subscriber Match and Create policy sets.

In part six of this series I started in on the Subscriber Command Transform policy set.

In part seven of this series I continued through the EntitlementsImpl policy in the Command Transform.

In part eight of this series I finished up the Command Transform and started into the Output Transform.

In part nine of this series I finished walking through the Output Transform.

In part ten of this series I started down the Input Transform policy set getting through the first six policy objects.

In part eleven of this series I finished the Input Transform policy set and got through the Publisher Event Transform policy set.

In part twelve of this series I got through the Match, Create, Placement, and almost all of the Command transform policy sets.

In part thirteen of this series I finished the Publisher channel, wrapping up the driver.

In part fourteen of this series I started comparing the newest packages, to the ones I actually reviewed.

In part fifteen of this series I continued comparing the newest packages, to the ones I actually reviewed.

Still in the Office 365 Default Configuration package, now on the Subscriber Command Transform policy set.

NOVLOFFIDCFG-sub-ctp-Rename

This policy has two major changes, and a policy linkage change. It is worth noting, that with advent of D4.02 Auto Update 4 I believe a new option for linkages was added. Now, the linkage information is actually stored in eDirectory in the Identity Vault in a new attribute DirXML-pkgLinkages, which holds XML describing the linkage.

In this case, the new version is:

<?xml version="1.0" encoding="UTF-8"?><policy-linkage>
	<policy-set channel="subscriber" name="command" order="weight" value="300"/>
</policy-linkage>

The change is, previously the value was 500. You can see that the channel is defined as Subscriber. I imagine Input or Output transform just ignore this value, and name tells us the name of the policy set. I imagine there is one for each policy set. Order allows for weight, last, first, after, before. Then the value meaning will change as appropriate.

Designer shows two major differences in the policy, the first being the addition of a condition (Class = user) to the "map rename to user modify" rule.

This uses the Source DN ultimately (Set a rule or two earlier, after it was cleansed from illegal character) instead of the CN, and for users sticks the @ domain GCV value onto the end of it. In fact it sets the CN value here, since that is mapped to the right thing in Office 365.

Now recall that in this policy the first object rejected any events that are not renames, so just setting the CN will suffice. Then the rename gets stripped out at the end, so only a modify event gets through of the CN. Resulting in a functional rename in Office 365.

For Groups, however the CN is set as simply the object-name, no @domain added. I need to look in Office 365 but that is interesting, since I guess a group does not have a UPN? The UPN for a user is basically the email address as well, so for a group, I guess you name the group, but give it a different EmailAddresses value. (Which I note I have yet to see 'flattened' from its structured format).

NOVLOFFIDCFG-sub-mp

This policy gets 6 changes, per Designers compare. First up in the Match Users rule, an extra condition of testing for the operation = add. (Amusingly they left it as a regex compare, not case insensitive as it defaults. I am guessing in development they thought they might use add|modify perhaps, so a regex compare there makes sense, but then realized only add was needed. Not an issue, and you only see it in the XML if you look, and has no affect on functionality, but hey, as a policy snob, this is the kind of nit picking I like to indulge in).

Now in the same rule, it used to have a single Find Matching Object query for CN but now does a second Find Matching Object for DisplayName, based on the eDirectory Full Name. I remain unconvinced that is a good idea, since Full Name is horribly unreliable. (How many John Smith's do you know, or if you wish to be multicultural Aditya Vikram's (Heck there is an aircraft carrier named VikramAditya in the Indian Navy).

The next change actually clarifies this a bit, since it changes what was previously an attempt to match on DisplayName for Users and Group, into just a Group attempt, and to use CN in eDirectory as the DisplayName in Office 365.

This is a smart change. That is, User's can be named by CN or Full Name, but groups DisplayName will be based on the CN so this was a good changeup to better catch matching objects.

Next up is the NOVLOFFIPSWD - Password Synchronization package that changed. It went from 2.1.0.20130110125335 to 2.3.0.20130907194140 with an intermediate 2.2.0 stage.

First off the readme was updated (yay!), and now adds:

*************
Office 365 driver package for Password Synchronization
*****************
-2.3
https://bugzilla.novell.com/show_bug.cgi?id=827396

-2.2 Changes made for enhancement to support DistributionList group.

https://bugzilla.novell.com/show_bug.cgi?id=811957

This helps since it give leads to follow in seeing what changed and why. It also confirms the trend I noticed in the beginning that the 2.2 release was all about distribution lists (I suppose if I had more spare time I could compare just that version to 2.1 and see if that is correct, but I don't, so I won't) and that 2.3 was all about bug fixes.

In this package we have a GCV, 2 policy and 1 resource changes.

GCV:

• NOVLOFFIPSWD-GCVs

Policies:

• NOVLOFFIPSWD-otp-Transform

• NOVLOFFIPSWD-sub-ctp-TransformPwd (Deletion of)

Resource:

• NOVLOFFIPSWD-GCVs-Prompt

Starting with the GCV, there are four differences. The first is a new GCV: StrongPasswordRequired with a description that says "Set this value to true to enforce strong password requirement for a user password.". Hmm, I look forward to seeing how they calculate a strong password. I have written a package that will go through a tree and report on users password strength. This was aimed at Active Directory passwords, so I was checking for a variety of different strength items (Length, 3 of 4, username in the password, name parts in the password). Initially I had it report WHY the password was weak, but the customer I did it for did not even want to know that much info, and I had to change it to just report weak or strong. Thus I am very interested in how they approached it.

The second change is kind of funny. In a normal Password Policy GCV set there is enable-password-publish, which is an enum (enumeration) type with true or false options. The original package only had the false option, since I guess there is no way to get passwords out of O365. Now they added in the true possibility, but I doubt they can get passwords out of O365 regardless.

Same thing with publish-password-to-nds, the true option was missing.

Followed by publish-password-to-dp adding in the missing true option.

This is probably just to bring this in line with other drivers so it looks less different.

So far not much change, but one interesting new GCV I await seeing how it is used.

Now onto the policy changes:

NOVLOFFIPSWD-otp-Transform

Designer shows only 3 differences, but there are two big ones and a small one and encompass almost the entire policy objects XML.

The first change seems to be the deletion of a rule called "Move User add Password", for when in an add, you hada <password> node but no add-value for an attribute named password. This rule used to convert the <password> node to an <add-attr attr-name="Password"> node with a value (content supressed).

Then it was followed by two rules that set first ForceChangePassword to false (i.e. Do not change password on first login, which would defeat the point of syncing a password change) and second set PasswordNeverExpires.

In the new config, those two values are still set, but the GCV StrongPasswordRequired is tested, and if true, the StrongPasswordRequired value is set to true, and if false to false.

I shall quibble again on the approach taken in all 4 of these attribute events. They use a Add Destination Attribute Value token, then using Append XML Element, shove in a <remove-all-values> node (even on an <add> event, which is nonsensical).

They could have simply used a Set Destination Attribute Value which always includes a <remove-all-values> node. Subtle things, and snobbish, I concede, but worth talking about.

Alas, that answers my Strong Password question, of how they would test for it. They don't. It is a setting in Office 365 being set, and I guess your passwords need to be strong when you send them through, and you rely on Password POlicies and your password change tool to enforce them.

NOVLOFFIPSWD-sub-ctp-TransformPwd

This is actually a delete of the policy from the newer package version.

What is interesting is you see the old style of linkage handling, where this is a sort of attribute 'placement' that says <placement location="subscriber"/>

Whereas policy-linkage would say:

<policy-linkage>
	<policy-set channel="subscriber" name="command" order="weight" value="1000"/>
</policy-linkage>

You can see how they can carry much more information in the new format. I guess they needed an attribute since this placement 'sort of' attribute is probably not really represented in eDirectory, so the need for a new one to map to eDirectory and store the value.

NOVLOFFIPSWD-GCVs-Prompt

Finally we have a Resource for the GCV Prompt object, where the change is to add support for the StrongPasswordRequired GCV.

Next up is the Package NOVLOFFENT - Entitlement support, which went from version 2.1.0.20130110181516 to version 2.2.0.20130627174421.

The readme was updated (Yay!) with a typo fixed (They copied it from AD and modified it and left an Exchange reference in, that was completely harmless) and some new info for the 2.2.0 release:

2.2.0 - Following bugs fixed.
https://bugzilla.novell.com/show_bug.cgi?id=798827
https://bugzilla.novell.com/show_bug.cgi?id=798942

Designer shows changes in four Entitlement objects, one GCV, two policies, and four resource objects.

Entitlements:

• Group

• License

• Role

• UserAccount

GCVs:

• NOVLOFFIENTEX-GCVs

Policies:

• NOVLOFFIENTEX-itp-EntitlementsImpl

• NOVLOFFIENTEX-sub-ctp-EntitlementImpl

Resources:

• L10N_de

• L10N_en

• BOVLOFFIENTEX-Filter

• NOVLOFFIENTEX-GCVs

Lets start with Entitlement objects. The Group, Role, and UserAccount do not look like they have changed at all, probably a whitespace change, that affects the checksum, but not an XML compare.

License changes, and looks like it fixed a minor typo in the Display Name for the retrieved, query based entitlement value. It was AccountName, but was changed to AccountSkuId. The value was properly being used, but the display was wrong so this resolves that issue.

The GCV object NOVLOFFIENTEX-GCVs changed with 5 items flagged in the compare.

First up we get a header change removing Exchange from the verbiage.

The remaining four are all about fixing the typo I reported that the GCV says, JASON instead of JSON. You can see how easy that is to confuse. If everyone talks to you about JSON and you never see it written down, how would write it down? Probably with an A. At the time I noted it was of 0 value in terms of functionality but it was important to fix because it makes them look bad. I am glad to see they actually did fix a cosmetic thing like this. (Especially once you are re-building the package it takes all of 1 minute to do).

On to policies now. First up:

NOVLOFFIENTEX-itp-EntitlementsImpl

A simple change here, fixing some strange escaping of characters. Before the XML showed

<token-xpath expression="es:getEntParamField($current-node,'ID')
"/>

and is now fixed as:

<token-xpath expression="es:getEntParamField($current-node,'ID')"/>

The apostrophes are no longer escaped and I think the ampersand, pounx, x, a, semicolon was a trailing carriage return. I have found stuff like this all over the XSLT and XML in various drivers, and I am yet unclear if it matters or if it counts as whitespace and is ignored, but it is nice to see it fixed.

That is the only change too!

NOVLOFFIENTEX-sub-ctp-EntitlementImpl

This policy had three instances of the same extra escaping and carriage returns cleaned up in the same way as the previous one. Good work guys! I reported that bug I think, and glad to see it fixed.

Lets finish the resources, and finish up this package.

The four Resources are:

• L10N_de

• L10N_en

• BOVLOFFIENTEX-Filter

• NOVLOFFIENTEX-GCVs

and none of them show any changes, they all look like whitespace changes since the XML is identical.

Finally the last package that changed NOVLOFFIATRK - Account tracking for Identity Audit from version 2.1.0.20130101164900 to version 2.2.0.20130513160359.

Looks like there are only two changed objects here; the NOVLIATRK-itp-publish2 and a GCV prompt.

The Input Transform policy object, NOVLIATRK-itp-publish2,

The main change here looks like an optimization for a rule meant to process retry events. Before, there was one large block of conditions, starting with an If XPATH test, of @level='retry' but now they did the opposite, if XPATH not true for the same statement, and if so, do a break, since the next rule only should fire if it is a Retry. Since this condition was the first one in the condition block, I remain unconvinced this will make any sort of real world difference.

The NOVLIATRK-GCV-Prompt does not have any visible changes, looks like another whitespace compare issue.

That finally seems to wrap up the entire series, soup to nuts. Who would have thought it would take this long! (Not me, that is for sure! I doubt I would have started if I knew it would take this long! (Shh, no one tell me next time either!)

I do hear rumours of a 2.4 package build and new shim, so maybe I will have one more to add after this.

Now which driver to do next? Any requests? I do take article requests. At some point I do sort of run out of ideas on what to write about. Driver walkthroughs are sort of easy ones, since every driver could use one.