[Freeipa-users] Python Client

Wed Feb 13 14:41:15 UTC 2013

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.

rob

>
> Thank you.
>
>
> On Tue, Feb 12, 2013 at 4:18 PM, Dmitri Pal <dpal at redhat.com
> <mailto:dpal at redhat.com>> wrote:
>
>     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 <dpal at redhat.com
>     <mailto:dpal at redhat.com>> wrote:
>      >
>      >> On 02/09/2013 11:53 AM, John Dennis wrote:
>      >>> On 02/08/2013 05:29 PM, It Meme wrote:
>      >>>> Hi:
>      >>>>
>      >>>> Scenario:
>      >>>>
>      >>>> 1) User is created via LDAP call to IPA (i.e.the 389 Directory
>     Server)
>      >>>>
>      >>>> 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
>     trying
>      >>> to bypass it. Why? Because we implement additional logic inside the
>      >>> commands. If you could achieve everything IPA does by just
>     modifying
>      >>> 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
>     the IPA
>      >>> commands that manage users and groups. You really don't want to
>     bypass
>      >>> it.
>      >>>
>      >>> 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
>     there
>      >>> 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
>     Martin
>      >>> shows how it can be done in in about half a dozen lines of code.
>      >>>
>      >>>
>     https://www.redhat.com/archives/freeipa-users/2012-June/msg00334.html
>      >>>
>      >>> What I'm not understanding why you're avoiding using the
>     commands we
>      >>> provide. If you're not familiar with how to call another
>      >>> program/process we can help you or just google it. Or is the
>     problem
>      >>> your existing management system does not provide you with any
>     "hooks"
>      >>> to execute code when an action occurs. But from everything
>     you've said
>      >>> so far you imply it does provide such hooks. Perhaps if you
>     could be
>      >>> more specific we could be more helpful.
>      >> It seems that the management system in question can insert an
>     entry into
>      >> 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
>      >> Freeipa-users at redhat.com <mailto:Freeipa-users at redhat.com>
>      >> https://www.redhat.com/mailman/listinfo/freeipa-users
>
>
>     --
>     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
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>