AD Password Hook - Install

[mubarakshabna_asmi]

I went through the Password Hook Configuration guide and have a few basis questions:

1. The password hook install is done on the domain controller of the AD , right?

2. If so how do you connect the IC and the password hook on AD. How does the password hook know where the IC is?

Any help/direction is much appreciated.

Thanks

Shabna

[Former Member]

Yes - you need to install DSE on the domain controller. You can construct the job which then sends the passwords to a temporary table in the IDS database and from there read / ecrypt them into your MX_PERSON objects.

The local job is called from the hook iirc using the command line option.

I created a temporary table which had the UID, Password, Status rows. The status row allowed the IDC pass to set a status so it didn't miss anything.

Pass 1: Set all status to 'pending' or some such

Pass 2: Get all 'pending' passwords and apply them to the user object

Pass 3: Delete all 'pending' passwords from the temporary table.

This ensures that if a password is written to the temporary table between pass 2 and 3 it won't get deleted.

If you run this job every few seconds on the IDC machine, it ensures that they are in there for the least amount of time possible. While you can encrypt them between the AD box and the IDC box, they can still be retrieved from the DB pretty easily. Encrypt them into the identity store as soon as you can.

Hope this helps

[mubarakshabna_asmi]

Any ideas. What am I missing.

[Former Member]

Hi

As I understand this (I havn't done this myself yet, so I can only guess) you need to install the Runtime-Component (including a dispatcher) on the DC.

The Hook calls the RT/dispatcher, and this one knows where your identtiy store is located. Maybe you will have to edit the dispatcher script manually. Or you can create that on your IdM-System, edit it afterwards and install it as a service on your DC

Just some thoughts. Hope I could help.

BR

Michael

[mubarakshabna_asmi]

Does this mean SAP expects the IC to reside on the Domain Controller. Because in the hook config the value of parameters like "Password notification program" mentioned in "Section 2: Configuring the Password Hook" and "Section 3: Integrating with the Identity Center" are identical.

Micheal, Have you tried/are you using Password Hook to any extent.

Thanks

Shabna

[Former Member]

I just played around with the Password Hook and this was on a DC where IdM was installed, so I haven't done the scenario you are facing.

But as I think you can install only the IdM-Runtime (DSE) on the DC.

This one is able to run a "*,dse" job using an installed dispatcher. The dispatcher knows where the IC resides.

You can also install the MMC on the DC and connect to your "remote" IC, configure a dispatcher and edit the DSE-Job...

In my head it works

You will have to wait for more qualified answers from people who already implemented your scenario. Good luck...

[mubarakshabna_asmi]

Thanks for your replies. This is what I did.

Installed MC and RT components on the DC. Connected to the database on the original IC. Setup the dispatcher.

Installed the Password hook on DC. The installation process did not show any errors, but I noticed that the install log says new dlls and ocx files are copied to C:\winodws\system32 folder and registry entries are made. I see the entries in registry but the file do not exsit in system32. So I manually extracted and put files in system32.

I was able to do the configuration and enable hook. Ran TestHook.exe and it runs fine.

If I run

C:\IDD\DESRT.exe "C:\IDD\Password Hook\newpass.dse "-D<user>=%1" "-D<pwd>=%2" from the command prompt it works

But when I actually reset password for the same user in AD the job is not triggered.

Do you see anything wrong.

Thanks

Shabna

[Former Member]

Hi

Sorry, but I can only quote the Hook Configuration Guide on page 13:

If everything is ok when using the test program, but fails on actual password changes, the cause is most likely in the user environment.
When you execute the test program, everything is executed in the context of the logged on user, with its access rights, and environment.
When the notification and filter programs are called from the system on a real password change, everything is executed in the context of the system account.
This might cause problems if the program(s) called depend(s) on environment variables, specific accesses or needs to interact with the desktop.

What OS you use? Maybe you have some restrictions (e.g. as in 2008 Server). Look at the Permissions set on the Password-Hook files and if System-account has access (to the bat-file, the dlls, ...). If the Hook is some kind of Windows-Service (not sure about that) you can activate a checkmark saying sth. like "Exchange data between Service and Desktop". Maybe you set/use some environment variables set only for the user and not for the whole system?

This issue is hard to remote-debug

BR

Michael

[Former Member]

Shabnam,

The PW Hook only uses the runtime engine (DSERT.EXE) which does not require a dispatcher.

This component along with the job and password hook DLL need to be installed on ALL domain controllers to properly capture password change requests. This is the way that all password change applications work. They need to be able to tap into the GINA of Windows. This means of course that the PW Hook will only work for Windows based accounts. However event driven takss can be set up to change passwords in other systems from NW IDM itself upon detection of a password change.

I always reccomend using full logging while testing, just remember to disable it when you're done so that you are secure and compliant!

Hope this helps...

Matt