It Meme wrote:
Thank you for your reply.
Could there be anyway that accounts can be provisioned to IPA, via LDAP,
from existing IAM system?
The newly provisioned accounts can be temporarily stored in IPA's 389
Directory Server, and subsequently an automated task can IPA-ize the
accounts (i.e. via the Python libraries). The accounts that have not
been IPA-ized will be provisioned in a disabled state (i.e. users will
be not using them).
After accounts have been IPA-ize, account attributes, such as
'givenName', 'password', 'membershipOf', can be managed by LDAP from the
central IAM system.
I think as has been suggested your best bet is to write the users to a
location outside of the IPA DIT and run a periodic query or write a
service that uses LDAP persistent search to retrieve the user then pass
it to the IPA framework via user-add. I think persistent search and a
user principal in a keytab would be a pretty decent way to go.
On Tue, Feb 12, 2013 at 4:18 PM, Dmitri Pal <d...@redhat.com
On 02/12/2013 12:42 PM, It Meme wrote:
> Yes - Dmitri is correct.
> Our purchased IAM product has LDAP connectors. It is possible to
customize to develop other connector protocols but it requires
tweaking the core product code - this adds risk and, if not careful,
could break our support with vendor or increase operational risk to
a critical production system.
> The most practical option is to continue to use the LDAP
connectors to provision accounts to directory server.
> If we use IPA, that would mean provisioning accounts, from our
IAM product to IPA, via LDAP (Step 1) - and subsequently running a
script that will call the python libraries to IPA-ize the
provisioned accounts (Step 2).
> It will assist our help desk staff if 'Step 1' provisioned
accounts were created in main accounts tree in IPA - then subsequent
script will IPA-ize the accounts for 'Step 2' and accounts will be
updated in same tree.
> Any gotchas foreseen with above?
Yes. You need to be very careful. You are bypassing all the checks that
framework creates around user and group management. It is also unclear
how the system would react to the half baked user. It is all doable but
you shift the risk from the tweaking core product code to creating a
custom IPA code. IMO the level of risk is nearly the same.
> We have larger user base with ~40K new accounts per year and 600K
ongoing - automating the tasks in stable systems, and having help
desk insight to account statuses are critical items for management.
> Thank you for your help, insights, input - they are very helpful
and greatly appreciated.
> On 2013-02-10, at 7:32, Dmitri Pal <d...@redhat.com
>> On 02/09/2013 11:53 AM, John Dennis wrote:
>>> On 02/08/2013 05:29 PM, It Meme wrote:
>>>> 1) User is created via LDAP call to IPA (i.e.the 389 Directory
>>>> The above user will not have IPA-specific attributes.
>>>> Can we use the Python Library, or CLI, to modify the account to
>>>> IPA-ize it?
>>> You're really better off using the IPA API directly rather than
>>> to bypass it. Why? Because we implement additional logic inside the
>>> commands. If you could achieve everything IPA does by just
>>> an LDAP server there wouldn't be a need for IPA. A good example of
>>> this is group membership, some of that logic is handled
directly by a
>>> plugin to the 389 DS, but a large part of it is implemented in
>>> commands that manage users and groups. You really don't want to
>>> You have a number of options on how to call the IPA commands:
>>> 1) the ipa command line client
>>> 2) sending the command formatted in JSON to the server
>>> 3) sending the command formatted in XML-RPC to the server
>>> 4) calling the command from your own python code
>>> 5) using the web GUI
>>> It's really not hard to call the IPA command line client from a
>>> program, typically this is done via a "system" command of which
>>> are a number of variants.
>>> The following thread has a discussion of how to invoke one of our
>>> commands from Python code, this particular email response from
>>> shows how it can be done in in about half a dozen lines of code.
>>> What I'm not understanding why you're avoiding using the
>>> provide. If you're not familiar with how to call another
>>> program/process we can help you or just google it. Or is the
>>> your existing management system does not provide you with any
>>> to execute code when an action occurs. But from everything
>>> so far you imply it does provide such hooks. Perhaps if you
>>> more specific we could be more helpful.
>> It seems that the management system in question can insert an
>> LDAP but can't do the "generic" hook.
>> I bet this is the issue here.
>> Thank you,
>> Dmitri Pal
>> Sr. Engineering Manager for IdM portfolio
>> Red Hat Inc.
>> Looking to carve out IT costs?
>> www.redhat.com/carveoutcosts/ <http://www.redhat.com/carveoutcosts/>
>> Freeipa-users mailing list
>> Freeipaemail@example.com <mailto:Freeipafirstname.lastname@example.org>
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
Looking to carve out IT costs?
Freeipa-users mailing list
Freeipa-users mailing list