Provisioning to AD - Is SSL mandatory ?

[Former Member]

Hi Experts,

We are in process of designing out landscape for NW IDM 7.1 ( HP UX with Oracle). We have a SAP Portal which will be using AD ( 2003) .

We will be provisioing users onto AD. Is it mandatory to use a SLL connecetion from NW IDM to AD ? or is it optionla securirity feature that will be used in case the company security policy demands it ?

Also what are the licensing considerations for users which are in Produtive AD. How does SAP count those users ?

Thanks,

Shailesh

[former_member2987]

Shailesh,

SSL is not required for AD provisioning. As a best practice, if you have to go between domains, SSL is a good idea, but if you're behind the firewall, traffic over 389 is fine.

The only exception to this is if you are doing password provisioning. From my experience, the password reset tasks that come with the framework use Microsoft APIs for pw provisioning and therefore do not require SSL. However, please do your own testing. Firewalls, GPOs, versions of Windows Server and AD can all have a bearing on this.

As far as licensing costs go, you should always check with your SAP representative for latest information.

Regards,

Matt

[Former Member]

Hi,

I agree with Matt, though we did found for one AD, that ssl was required for password setting, but when we transported this config via export and import and pointed it to a different domain, it didn't require ssl. My feeling is that it is a setting within AD that controls this, but I've yet to find out where that is.

Hope this helps,

Ian

[Former Member]

Hi,

I think using SSL is definitely the better way to set the AD password. The SAP Provisioning Framework bypasses the SSL requirement by using a Windows Script with ADSI commands to set the password.

I was told that the password function of ADSI uses DCOM. But DCOM requires a large port range to be opened and this might be an issue in a production environment.

Best regards

Holger

[former_member2987]

So Holger, in that way you're using a "To LDAP" over port 636 and setting userPassword? Or is it more than that? (I'm assuming the certificate has already been installed)

[Former Member]

Exactly. I have configured 636 to be the standard port in the repository configuration. In addition, I have configured SSL to be used in all toLDAP passes. The root certificate needs to be imported into the certificate store of the java runtime. And then you can use a simple ToLDAP pass that writes the password into the password attribute of AD (don't know the name of the attribute from the top of my head).

[Former Member]

Hi

Did you test that? Can you login to the domain in Windows with the password set by this toLDAP-pass?

I always thought userPassword is somehow encoded and that there's no way to set it directly using LDAP, neither with ssl nor with any other technology.

Do you set useraccountcontrol to 512?

Do you encode the userPassword or send it in clear-text?

What Windows-AD-version / schema do you use?

BR

Kanan

[Former Member]

Hi Kanan,

yes, I tested that : it worked and I could log-in. But unfortunately I cannot find the code at the moment, so I don't know which attribute I used (but there are only 2 password attributes in AD).

The password does not need to be encoded - Windows will take care of that. I tested it on W2K3. I first set the password and in the next pass I set the user account control flag.

Best regards

Holger

[former_member2987]

Does anyone know if there is a document out there that describes setting up the SSL configuration? I think I saw something once, but can't remember where.

Even a generic Microsoft document on setting up the certificate relationship between the servers would be helpful.

Thanks

[Former Member]

Hi Matt,

I'm not aware of any documentation. But from the top of my head you have to perform the following steps in a test environment:

- Install Microsoft Enterprise Root CA and reboot the system

- After the reboot, AD will use a certificate from the CA and use SSL on port 636

- Export the Root CA certificate. The certificate can e.g. be downloaded from http://<machine of root ca>/certsrv

- Import the root CA certificate into the cacerts file in <jre>/lib/security. The default password of the cacerts file is "changeit" (the certificate can be imported using keytool).

Now the JRE trusts the CA certificate and you should be able to configure an SSL connection to AD in the ToLDAP pass.

Best regards

Holger

[former_member2987]

Holger,

I've got most of this working, but IDM does not seem to see AD on SSL. If I go on 389 all is well, if I go on 636. I did remember to switch the authentication to SSL, but I keep getting LDAP: Server down messages.

I tried connecting over 636 using an LDAP browser and that went fine.

Any ideas?

Thannks,

Matt

[Former Member]

Hi Matt

Did you remember to set the runtime engine to Java? I got the LDAP:Server Down message when the runtime engine was set to Windows.

By the way - I have some trouble after setting the pasword using SSL. The job is running succesfull, but I can't logon using the password. The (complex) password was written thru the userPassword attribute as clear text in a to LDAP pass using SSL (Security option and port 636).

Does anybody have an explanation?

Kind Regards

Olaf Bertelsen

[Former Member]

Hi Olaf

I'm working on IDM 7.2 SP4 with SAP Provisioning Framework. I've successfully connected to MS AD for provisioning.

While performing password reset using "Set AD User Password" task with SSL and attribute "UnicodePwd" ,the job completes successfully. But when I try to use the password to login to AD, it doesn't work.

I noticed that you've faced similar problem. Did you get any solution for this problem?

Thanks,

Anuj

[Former Member]

Added ! to the attribue unicodepwd in  "Set AD User Password" task. The attribute now appears as !unicodepwd in the task. The extra ! suggests LDAP that the received password in hex encoded.