Best way to encrypt temporary pasword in FIM?
Hi, My user creation process requires to generate a temporary password, which will be propagate to different targets (AD, OpenLDAP...). So, all accounts are not provision at the same time (for example, AD account requires some external validation before creation) but the same value should be used to set password for all targets. To secure this sensitive data, the temporary password should be encrypt before to store it in the FIMService database (SQL Server 2008). What is the best way to realize this? Is that FIM offers this feature? Should I develop a custom activity to encrypt and decrypt the value whit a reversible algorithm? Or perhaps an another mechanism linked to SQL Server? Thanks. Regards, H.
November 23rd, 2010 3:17am

Why do you think temporary password is a sensitive data? I would rather generate a random password and send it to person's immediate manager and forget about it. What do you afraid of? There's no protection from domain or database administrators anyway... and part of MIIS database is encrypted by MIIS itself
Free Windows Admin Tool Kit Click here and download it now
November 23rd, 2010 3:45am

Hi, In fact, I have to conserve the temporary password because it is not sent directly. I want to know if this value is stored in clear text in the FIMService database. The temporary password is generated by a custom activity in a workflow (FIM Portal). So, you said part of MIIS database is encrypted by MIIS itself. That means all data in FIMService database are already encrypted? Thanks in advance. Regards, H.
November 23rd, 2010 4:06am

I think the OP is trying to set the same password on multiple connected sources. Just like you can flow P@$$W0rd to uniCodePwd in AD. However if you randomize the PW in your OSR for AD, there's no way to get the same "randomized value" to be flown to other sources... Perhaps you can set a "randomized password" in AD, use PCNS to capture PW changes in AD and then have them be sent to the other MA's? A possible process could be the helpdesk resetting the user his password and communicating it to the user. This reset would trigger the update in the other systems and as such make sure the password is the same in all sources. But to be honest, I have no experience with this scenario.http://setspn.blogspot.com
Free Windows Admin Tool Kit Click here and download it now
November 23rd, 2010 4:08am

From what I can see in FIMService database all object text values are not encrypted. FIMSyncService database also keeps all text values unencrypted. But if you will you PCNS to sync AD password to your MA - password will not be stored in MV at all. another solution is (what I have) to have all provisioning logic in MVExtension .dll so you can flow random password to all MAs on new user provisioining as Thomas said.
November 23rd, 2010 4:35am

The password is not encrypted in the FIMSynchronizationService DB if you store it in a metaverse attribute. If you save the password to an external DB using a SQL MA then I believe you should be able to write an encrypted value onto the connector space object, and then out to the DB, using .NET methods. It won't be high security, especially as you presumably want to be able to de-encrypt the value, but it's something. The usual way is to use Password Sync. So you write the password straight to the AD account and then it's automatically sync'd to the other accounts. Of course you have to make sure the AD account is created last, and you still have the problem of not know what the password is (if it was random). I know some people use a predictable pattern - eg first and last letter of the surname plus DOB so at least it's complex, even though anyone who knows the pattern could work it out.http://www.wapshere.com/missmiis
Free Windows Admin Tool Kit Click here and download it now
November 23rd, 2010 6:18am

HI, Actually, the password should be encrypt with a reversible algoritm to be able to read it and sent it later. In brief, I have two solutions : - Develop a custom activity (or a rule extension) to encrypt and decrypt the temporary password with a reversible algorithm or more secure, - generate the random password just before to send it and use PCNS to propagate its value to the targets. In this case, I never store the temporary password. Therefore, this requires each user necessarily have an active directory account to perform the propagation. Right? thanks.
November 23rd, 2010 8:47am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics