So in a recent customer project I was wondering why a new JDBC driver did not sync the date of birth from user accounts to a database table. Everything else was working and the obvious checks for a typo or missing entry in filter or schema mapping  showed everything just fine. So I captured a level 3 trace of a sync event and found this as part of the query result from the merge processor:

<attr attr-name="aieUserDoB" is-sensitive="true"><!-- content suppressed -->
 </attr>

Ok, so the attribute is in filter and gets read in a merge, so far so good. But -sensitive="true"? Who flagged that custom aux attribute as sensitive? I certainly did not do that in policy...

Anyway, consequently subscriber command transforms saw the following as part of the resulting synthetic modify:

<modify-attr attr-name="aieUserDoB"><!-- content suppressed --><!-- content suppressed -->
 </modify-attr>

So the merge profcessor did it's job as expected, the attribute made it into command transforms, next comes the subscriber notify filter:

 [07/23/18 16:39:11.107]:AIM-MetaStore ST:Filtering out notification-only attributes.
 [07/23/18 16:39:11.107]:AIM-MetaStore ST:Filtering out attributes that require a secure channel.
 [07/23/18 16:39:11.107]:AIM-MetaStore ST: Filtered out <modify-attr attr-name='aieUserDoB'>.

"Filtering out attributes that require a secure channel", really? I do not recall having seen this before, to be honest but it somehow makes sense. If you sync an attribute over an insecure channel (whatever that means...) it could be read in the clear on the way - something you do not want to happen for anything explicitly flagged as "is-sensitive"!

So where does it come from? It turned out, the customer had created an Encrypted Attribute policy for some of the attributes considered sensitive, including birth dates. This can be done via iManager with the eDirectory Encryption plugin. You basically define a list of attributes and an encryption algorithm to use (like AES, Triple DES etc.) and assign it to a server object. The server will then encrypt the listed attributes on disk (and you can add Encrypted Replication on a per-partition basis for good measure). IDM on the other hand will hide those attribute's values in trace much like it does for passwords.

And then there's one more option in those encryption policies that comes into play here: a little checkbox labeled: "Always require Secure channel for Client access". It seems as if this is what makes the engine strip sensitive attributes in subscriber notify filter (which should be renamed to "Subscriber Notify and Security Filter", I guess) in recent IDM versions.

So what's a "Secure Channel" in this context? I did not find that explained in all detail in the docs (anyone with better search-fu than me? Please post a link in the comments below.) but I assume it's basically this:
- having TLS configured for Remote Loader connection
- having TLS configured for drivers that support it as part of the shim parameters or authentication settings

In my case I was using a Remote Loader connection that was limited to localhost connections on both sides by setting

 localaddress=127.0.0.1

in the "Other Parameters" on the driver's authentication tab and

 -connection "port=8090 address=127.0.0.1 fromaddress=127.0.0.1"

in the remote loader config. This should effectively prevent anyone from snooping on the network for the transmitted data, but root would still be able to tap into this. Now even root on a Linux eDirectory server could not decrypt encrypted attributes without a proper Edir login, so it makes sense to require TLS here as well.

Et voilà, once I've set up certs and the connection was running over TLS the missing field happily started to flow into the database...

I ran into this on a box running Edir 9.0.4 and IDM 4.6.1 - anyone with an idea for the minimum eDirectory and IDM versions required to enable this feature? Please let me know in the comment section...