Univention Bugzilla – Bug 48830
samba password filter / ADsync / Odin / Parallels
Last modified: 2019-03-01 12:41:19 CET
It would be nice to have a connector to sync out the passwords to an odin AD which is used for example in external hosted exchange services some specs https://kb.cloudblue.com/en/111156 further description https://help.univention.com/t/passwort-sync-nach-aussen-fur-parallels-odin/4411 Its an external "AD" though it wants to be talked to (only push) in a specific xml file format via https. The current adsync.exe solution uses the " password filter " hook in windows server to read out the passwords - so I assume they have to be intercepted as plain values and possibly hashed by a separate algorithm. To program such a solution myself - what would be the fist steps? i guess https://github.com/univention/univention-corporate-server/tree/4.3-3/services/univention-ad-connector might be a start - all code seems to be in python which is nice - though I don't know it a "password filter" is possible from the python layer .. I assume it has to interact with higher privileges with samba - I couldn't find a " password filter " hook documented in samba4 (unless one tells samba to store plaintext versions of the passwords and interprets them afterwards - but that is a bit so-so .. )
The main blocker here is that it looks like Parallels doesn't provide an open specification of the protocol that they use in their POA CDI solution for the communication between their ADSynchronizationAgent.exe (which you are supposed to install on one of your MS AD DCs) and the AD Sync web service. Quoting relevant passages of http://download.pa.parallels.com/poa/5.5/doc/pdf/Customer%20Directory%20Integration/poa_5.5_cdi_users_guide.pdf : =============================================================================== "ADSynchronizationAgent.exe. This component is responsible for scanning external Active Directory and communication with the AD Sync web service over the internet." =============================================================================== The second thing is their AD password filter, quoting the same documentation: =============================================================================== "ADPasswordChangeFilter.exe. Password Filter is a DLL that runs within the Local Security Authority process of every Domain Controller in the domain. It intercepts all the password change events and sends the new password data to the Password Change Listener. The Password Change Listener is embedded into the AD Synchronization Agent, which communicates with the AD Sync web service. The communication between the AD Synchronization Agent and AD Sync web service is performed over SSL-encrypted connection." =============================================================================== FYI: AD password filters * have to be installed on each MS AD DC in your domain * intercept password changes and send the password data to the filter plugin (see https://docs.microsoft.com/en-us/windows/desktop/SecMgmt/password-filters ) This is in stark contrast to what our product components do (AD-Connector, S4-Connector), which don't see and don't exfiltrate plain text passwords from AD or Samba. Our connectors only read and write password hashes and kerberos keys. Also, Samba currently doesn't implement Active Directory style password filters, AFAIK. It's possible in principle, but currently we don't see a good reason do do this. Even if we had the plain text passwords, we cannot sync them do Parallels without an open protocol specificaion of what their AD sync web service expects. It transfers the data via SSL, but there's probably more protocol to follow, e.g. how they handle authentication and how they encode the data. Maybe it's just the XML file you mentioned, but maybe not.