HI Folks - We have a scenario where Tivoli Access Manager is being used as a reverse proxy and it has its own LDAP - Tivoli product. The developer who is building an SSO solution with TAM says he needs passwords that are encrypted (when stored) in the TAM LDAP, not hashes for whatever reason. We also have AD in the environment that serves as the primary source for accounts so the thinking it that we should sync AD passwords to the TAM LDAP and folks can use the same credentials when using TAM or AD. However, if AD stores only hashes for passwords, we would be sync'ing the hashes only, right? The developer said he must have the encrypted password, not the hash. So: 1.) Is there a way to sync the encrypted password, not the hash using Forefront IDM sync? 2.) Does FIM require passwords to be stored in a certain format? Thank you!

Hi! There's a MA/connector for TDS (Management Agent for IBM Directory Server, supports "IBM Tivoli Directory Server 6.2" according to http://technet.microsoft.com/en-us/library/ff608275(WS.10).aspx, which supports password synchronization according to; http://technet.microsoft.com/en-us/library/cc720670(v=ws.10).aspx. So in this scenario I'd setup PCNS (Password Change Notification Services) on your AD DC's with applicable configuration to send password synchronization requests to FIM, configure a TDS MA with proper join rules to join the existing TDS account to the MV object (which is joined to the "corresponding" account in AD) and enable password synchronization on the MA. This is a bit more involved than what I just explained, have a look at the documentation: http://technet.microsoft.com/en-us/library/839a9291-a78f-4959-8e6a-3bf68bf62700 and http://technet.microsoft.com/en-us/library/cc720654(WS.10).aspx might be good starting points. Best Regards Tobias

Agreed with Tobias on the built-in IBM/Tivoli DS MA. With regard to FIM/ILM/MIIS password sync, the encrypted plaintext password is made available to FIM via the PCNS add-in for AD, so that it can be propagated to other systems that may each use their own storage mechanisms. The PCNS kicks in before AD hashes/encrypts/stores each new password, but after AD has agreed to accept it.

Agreed with Tobias on the built-in IBM/Tivoli DS MA. With regard to FIM/ILM/MIIS password sync, the encrypted plaintext password is made available to FIM via the PCNS add-in for AD, so that it can be propagated to other systems that may each use their own storage mechanisms. The PCNS kicks in before AD hashes/encrypts/stores each new password, but after AD has agreed to accept it. I'd add also that my experience with TDS is that you supply it with a hashed password (and presumably the password extension in the Tivoli MA does as much). I'm not sure I follow what the TAM dev says he needs a reversible password for.My Book - Active Directory, 4th Edition My Blog - www.briandesmond.com

Most non-AD LDAP servers store the hashed password in a field you can read and write in the regular way with administrative credentials; one very common form is "{hashformat}base64string", e.g., "{SSHA}Jjfklw93jfKJLFEW==" or "{crypt}IoweFEjflA=" and the like. I think this is what TDS does although it's been a little while.

Thanks for everyone's reply - seems like there is more than one way to skin this cat. WIll be sure to share what we determine the best method to solve the problem

There's always several ways to skin cats, and to give you one more way to skin it I will add this to my previous answer: You could create your own ECMA2-connector that more or less just implements the password synchronization capabilities and use the unencrypted password anyway you'd like. I've seen implementations where just the password sync methods have been overridden to give the possibility of persisting the unencrypted password before calling the overridden base method. Let me know if you need more info about that or guidance on how to integrate/communicate with TDS.