We have a client trying to use a bought in application against a DSfW
source. It makes LDAP calls to update its own database. It checks for
recently modified user accounts by executing an LDAP query that tests the
whenChanged attribute against a base date/time value given as an AD
generalized date string

It is failing to retrieve any records from DSfW because it looks to me that
this attribute is not being presented via LDAP in an AD date format, but in
a native eDirectory form:

whenChanged = yyyymmddhhmmssZ rather than the AD format yyyymmddhhmmss.0Z

I notice also that the trailing Z format of the underlying eDir is also
seemingly exposed for the following common AD attributes in LDAP:
which I'm sure could also cause queries expecting native AD LDAP to give
wrong results also.

Like a previous issue I recently saw with the logonHours and VMware View,
this appears to me to be a bug, but hopefully something that can be shimmed.
Of so do I need to raise an SR?