Knowledge Partner
Knowledge Partner
210 views

Re: AD Integration with IDM 4.0.2 with user's limited permission

On 7/26/2012 4:46 AM, rajeshemailto wrote:
>
> Dear Specialists,
>
> We are integrating AD with IDM 4.0.2 using "*-Three Server
> Configuration-*" as per mentioned in ad.pdf, Section 2.2.4. A per same
> document's Section 2.4, *Administrative Account* must have following
> permission:
> 1. Must be a member of the *Administrative* group
> 2. Read access at the root of the domain
> 3. Replicating Directory Change rights at the root of the domain
>
> Above (2) & (3) are acceptable by client's organization policy but for
> (1) we need to clarify what do we mean by *Administrative* group. I
> believe, its is one of


#1 is meant to provide access to read and write attributes in AD. It
does not (I believe) HAVE To be a Domain Admin. But whatever rights you
give it instead, are basically what it can do. So if it cannot delete
groups, then sending a delete event for a group, will not work.

So figure out what your driver is allowed to do and give it just those
rights instead of Domain Admin.

> - Domain Administrator
> - Local Administrator Group of Application Server
>
>
> Also, AD is not having any LDAP SSL enabled. Can we configure password
> sync without SSL communication between AD server & Remote Loader
> server?


No. As I understand it, the AD API's won't let you send the password in
clear text. (Or maybe Novell enforced it, it was never clear), but this
will fail without SSL enabled on AD.




> Looking forward for your valuable response.
>
>


Labels (1)
0 Likes
7 Replies
Anonymous_User Absent Member.
Absent Member.

Re: AD Integration with IDM 4.0.2 with user's limited permission

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>> Also, AD is not having any LDAP SSL enabled. Can we configure
>> password sync without SSL communication between AD server & Remote
>> Loader server?

>
> No. As I understand it, the AD API's won't let you send the password
> in clear text. (Or maybe Novell enforced it, it was never clear),
> but this will fail without SSL enabled on AD.


Does 'AD server' this case mean something other than a DC? If so, yes,
I think Geoffrey is right. If you put the RL on a DC as is the
best/easiest/safest practice (from all perspectives I believe, except
those which staunchly refuse to put anything on a "fragile DC" for
reasons that basically fall under "just because") then the communication
all seems to work without additional configuration on the MAD side.

Good luck.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJQEUbXAAoJEF+XTK08PnB5c7oQAMPKJXtv0ZFDNVor0n3y9tAB
ARvfNgh9fvaXgZw7DOGEh4DuN9H3d3M4TE0UaKXRuHdcHwbGY3uD6hkBrYDvA2Km
+o5QDxwez4T+7VNexZre3hIjrJ0vmpzKpQq7h0bBAortCnr4KX9Eh5ij8S4Re2GY
yMu7gm4UkVbPgQmDCPGHWfrhrHnLB8MqfeXQtVEyGzBqU17bNlo/+2xs+HYarISZ
rCKm/IspEh9v+gZWZ6ImJKTajIzDII++gEBFXiz82Dasm0xT42rNtekhXmfCiUIB
FRwGOibQ1CuhVpR6/9W19WvrgkaWXb1o4f47CpBHZTq5RGOsDoXoUlGqE0H+zxWi
TjIJYX0j/IPMVzJpKr6Nj8+HQ+OkrkYBW2f8CZ2sfqY4tD3gzvRn7RnHZ/WifY49
yI5hk7iLpJHXQbvhTEb5sckZyf81Y+PQCcZwJgJgJdPC+FECGU92rmzUsBvSPyhY
YBajU8qNmdPvZeAp4q2PVb1d5WF0KFjOczpRUgjqf970Bh0nT8+bE7UbXxl6WHIe
PiP/VmtbDK+sQZdEg8kWzRITStkCttXhLoL6UkOLBK3T3As8IV61v53OYR+UgdK6
DVw+kBRA8NdAP7n7J/ouaiPwTYlmeCwfHYEBlOSKaXTlWMD4lpnlWqUoH562PnDm
a+1YQ62c5MS/GZnlGJ9q
=RS+F
-----END PGP SIGNATURE-----
0 Likes
kenl Absent Member.
Absent Member.

Re: AD Integration with IDM 4.0.2 with user's limited permission

On 26/07/2012 13:40, Geoffrey Carman wrote:
> On 7/26/2012 4:46 AM, rajeshemailto wrote:
>>
>> Dear Specialists,
>>
>> We are integrating AD with IDM 4.0.2 using "*-Three Server
>> Configuration-*" as per mentioned in ad.pdf, Section 2.2.4. A per same
>> document's Section 2.4, *Administrative Account* must have following
>> permission:
>> 1. Must be a member of the *Administrative* group
>> 2. Read access at the root of the domain
>> 3. Replicating Directory Change rights at the root of the domain
>>
>> Above (2) & (3) are acceptable by client's organization policy but for
>> (1) we need to clarify what do we mean by *Administrative* group. I
>> believe, its is one of

>
> #1 is meant to provide access to read and write attributes in AD. It does not (I believe) HAVE To be a Domain Admin.
> But whatever rights you give it instead, are basically what it can do. So if it cannot delete groups, then sending a
> delete event for a group, will not work.
>
> So figure out what your driver is allowed to do and give it just those rights instead of Domain Admin.
>
>> - Domain Administrator
>> - Local Administrator Group of Application Server
>>
>>
>> Also, AD is not having any LDAP SSL enabled. Can we configure password
>> sync without SSL communication between AD server & Remote Loader
>> server?

>
> No. As I understand it, the AD API's won't let you send the password in clear text. (Or maybe Novell enforced it, it
> was never clear), but this will fail without SSL enabled on AD.
>
>
>
>
>> Looking forward for your valuable response.
>>
>>

>


Seem to recall that in the past (on an occasions when the client insisted that the remote loader be somewhere other than
a DC) that setting the AD driver to carry out Signing and Sealing allowed passwords to be asserted in AD. This still
needed an SSL protected connection from the vault to the remote Loader. Have not tried it for a while so my recollection
may be slightly off here but it's worth checking.
0 Likes
Knowledge Partner
Knowledge Partner

Re: AD Integration with IDM 4.0.2 with user's limited permission

On 27.07.2012 14:46, rajeshemailto wrote:
> Half of the way is thru but need to achieve Password Sync from AD to
> IDM too. After reviewing Novell Doc ad.pdf, I find it lil confusing. As
> per Section 2.5, it says:
>
>>
>> In order to retrieve a user�s password on the Publisher channel, the
>> driver requires system permissions in addition to Active Directory
>> permissions.
>> Identity Manager also configures specific permissions for its own
>> internal components. On domain controllers, the PWFilter component runs
>> using SYSTEM privileges, so the local system account should have full
>> permissions to the HKEY_LOCAL_MACHINE\SOFTWARE\Novell\PwFilter\Data
>> registry key, as well as any sub-keys.
>> The driver shim runs using SYSTEM privileges by default, so the system
>> account should also have full permissions to the
>> HKEY_LOCAL_MACHINE\SOFTWARE\Novell\PassSync\Data registry key, as well
>> as any sub-keys. If the driver is run using any other account, that
>> account should be given full permissions to the
>> HKEY_LOCAL_MACHINE\SOFTWARE\Novell\PwFilter\Data registry key, as well
>> as any sub-keys. The account should also be a member of the
>> Administrators group.
>>

>
> Since I am using three server configuration, we do not have any
> component on DC.


Even in the three-server configuration, you still MUST have password
sync filter installed on each domain controller.
and configured to send passwords to the server hosting the remote loader.

refer to chapter 6 - synchronising passwords, specifically section 6.2

>Registry key
> HKEY_LOCAL_MACHINE\SOFTWARE\Novell\PwFilter\Data are not available in
> DC.


The correct registry keys should appear on each DC when you have
properly installed/configured/loaded the password sync filter

> Also, in Remote Loader server, we have only
> *HKEY_LOCAL_MACHINE\SOFTWARE\Novell\PassSync\Data* available. Last line
> above says *The account should also be a member of the Administrators
> group.*. Which account it is talking about to have membership in
> Administrator group.


The Administrators group they refer to is the built in per-server
Administrators group. (SID S-1-5-32-544 - see
http://support.microsoft.com/kb/243330 for more details)

The account must be a member of this Administrators group on the server
hosting the remote loader/driver shim.

> Since, I am doing everything in my lab environment, need leads on
> setting up CA & build SSL communication across all windows & SUSE
> servers.


The NetIQ documentation explains how to set up the CA/SSL, refer to
chapter 6 - synchronising passwords.
Alex McHugh - Knowledge Partner - Stavanger, Norway
Who are the Knowledge Partners
If you appreciate my comments, please click the Like button.
If I have resolved your issue, please click the Accept as Solution button.
0 Likes
Knowledge Partner
Knowledge Partner

Re: AD Integration with IDM 4.0.2 with user's limited permission

On 8/3/2012 10:46 AM, rajeshemailto wrote:
>
> I am back with set of client's limitation & critical requirements. After
> doing POCs, we are able to do sync MAD with IDM using read access on
> root. Now, we got some limitation in client's environment due to
> security policies they have.
>
> Below are the limitation in their environment:
> - No installation should be done on any DCs across network.
> - User which will be used by AD driver should not be in "Domain
> Administration" group.
> - SSL is not enable on MAD so no SSL will be available.
>
> Requirements as follows:
> - Only subscriber channel will be active to replicate changes from MAD
> to IDM. No reverse changes applicable.
> - LDAP SSL is not available but Password sync required from MAD to IDM
> and to connected systems.
>
> After looking above scenario, I am stuck with following components:
> - User & Group are allowed to sync from MAD to IDM giving "Read" &
> "Replicate Change of Directory" permission to AD user which is used by
> AD Driver.
> - For password sync, we need SSL & pwfilter.dll to be installed on
> DCs. But client's Org policy does not allow to install any component on
> DCs & they do not have any SSL communication in place.


Not much to say. If nothing is allowed on DC's, then no Pub channel
password sync. With no SSL you may not be allowed to set passwords in
AD either. They seem to prefer to send passwords clear text over
encrypting them?

However, without SSL, and nothing on DC's a Remote Loader running on a
member server WILL be able to get events (just not passwords) out of AD
(Pub channel).

Be aware pretty much all products that wish to support catching password
changes out of AD will use the same technology approach of a password
filter. It uses an API Microsoft published, for much this purpose.


0 Likes
Knowledge Partner
Knowledge Partner

Re: AD Integration with IDM 4.0.2 with user's limited permission

On 8/4/2012 12:36 AM, rajeshemailto wrote:
>
> Thanks Geoffc!
>
> All above is clear except one thing, we are not writing password back
> to IDM to MAD (Sub). But we need password sync from MAD to IDM and we do
> not have SSL communication.


Without Password filters on the DC, you cannot do it anyway.

I am not sure if you did have the password filters, but no SSL if
passwords would flow. I would have to test to try.

> Can we achieve Password Sync from MAD to IDM (Sub Channel) without LDAP
> SSL communication?
>
> I'll implement this on my environment and see the changes.
>
> Regards,
> RK
>
>


0 Likes
Knowledge Partner
Knowledge Partner

Re: AD Integration with IDM 4.0.2 with user's limited permission

On 04.08.2012 10:06, rajeshemailto wrote:
>
> Hi,
>
> I reworked on registry to fix the issue and able to zeroing the
> "Registry" permission requirement as follows:
>
> Registry *"HKEY_LOCAL_MACHINE\SOFTWARE\Novell\PwFilter\Data"* on DC
> server, permission is given to *"SYSTEM"* with *"Full Control"*.
> Registry *"HKEY_LOCAL_MACHINE\SOFTWARE\Novell\PassSync\Data"* on
> Remote Loader server, permission given to
> - *"SYSTEM"* with *"FULL CONTROL"*
> - *"WIN-1USJD/Administrator" (Built-in
> Administrator)* with *"FULL CONTROL"*


I highly recommend that you don't change the registry permissions from
their default here. This has been known to cause problems.
This is noted in the documentation (section 2.5 of the AD driver
documentation)

It's generally better to ensure that the the AD driver service is run
via the local system account on the remote loader box. That way you
don't need to mess with registry permissions.

> Just to add, I am doing IDM & MAD integration with three server
> configuration as mentioned in 'Section 2.2.4 - Remote Installation on a
> Windows Member Server'
> (https://www.netiq.com/documentation/idm402drivers/ad/data/agdyjgz.html#but3i0v).


Alex McHugh - Knowledge Partner - Stavanger, Norway
Who are the Knowledge Partners
If you appreciate my comments, please click the Like button.
If I have resolved your issue, please click the Accept as Solution button.
0 Likes
wcscis Absent Member.
Absent Member.

Re: AD Integration with IDM 4.0.2 with user's limited permission

On 8/3/2012 9:46 AM, rajeshemailto wrote:
> Below are the limitation in their environment:
> - No installation should be done on any DCs across network.
> - User which will be used by AD driver should not be in "Domain
> Administration" group.
> - SSL is not enable on MAD so no SSL will be available.

If you are using a member server for your remote loader then you have to use the negotiate method on
the AD driver. The Microsoft protocol specifies that you must do this over SSL. So you must have
at least one DC (preferably two) that has LDAPS listening with a valid certificate.

The member server must then trust that certificate or its CA in the local machine trusted store. If
you don't do this you will get unreliable results.

The password sync filter is a fully supported, from Microsoft, method of getting passwords. In fact
their IDM product uses it too. So perhaps communicating this to the client will alleviate their
concerns.

Personally I think the member server installation is the best, preferred method to setup an AD
driver. You want that service independent of such a critical component as a domain controller and
you don't want to have to install Exchange tools etc on a DC.

If you can't install the remote loader on the DC and you can't get a DC with a cert then you are up
a creek and will have continual problems with the installation.

>
> Requirements as follows:
> - Only subscriber channel will be active to replicate changes from MAD
> to IDM. No reverse changes applicable.
> - LDAP SSL is not available but Password sync required from MAD to IDM
> and to connected systems.
>


0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.