<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 02/13/2013 12:47 AM, It Meme wrote:
    <blockquote
cite="mid:CA+h5jVyHrh0BSJiB67UiKTThWFtLjoyBwwLj-QwjvGnDXV=KoA@mail.gmail.com"
      type="cite">
      <div dir="ltr">Thank you for your reply.
        <div><br>
        </div>
        <div>Could there be anyway that accounts can be provisioned to
          IPA, via LDAP, from existing IAM system?</div>
        <div><br>
        </div>
        <div style="">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).</div>
        <div style=""><br>
        </div>
      </div>
    </blockquote>
    <blockquote
cite="mid:CA+h5jVyHrh0BSJiB67UiKTThWFtLjoyBwwLj-QwjvGnDXV=KoA@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div style="">After accounts have been IPA-ize, account
          attributes, such as 'givenName', 'password', 'membershipOf',
          can be managed by LDAP from the central IAM system.</div>
        <div style="">
          <br>
        </div>
      </div>
    </blockquote>
    <br>
    IMO a solution might be to do something like this:
    <a class="moz-txt-link-freetext" href="https://fedorahosted.org/freeipa/ticket/1593">https://fedorahosted.org/freeipa/ticket/1593</a><br>
    You create a plugin for DS to intercept the changes and send them
    over DBUS or socket<br>
    <br>
    So the whole thing would work like this:<br>
    You create a different tree for accounts managed by the external
    system for example under cn=ext, ...<br>
    You create a plugin that would intercept add, delete and modify
    commands and would also send these over the DBUS/Socket to a python
    service that would translate the changes into ipa user-add, ipa
    user-mod and ipa-user-del commands.<br>
    <br>
    The value of this approach is that would take advantage of the
    standard interfaces of both systems and have full control over the
    code you develop.<br>
    <br>
    Would that work for you?<br>
    <br>
    <br>
    <br>
    <br>
    <blockquote
cite="mid:CA+h5jVyHrh0BSJiB67UiKTThWFtLjoyBwwLj-QwjvGnDXV=KoA@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div style="">Thank you.</div>
      </div>
      <div class="gmail_extra"><br>
        <br>
        <div class="gmail_quote">On Tue, Feb 12, 2013 at 4:18 PM, Dmitri
          Pal <span dir="ltr"><<a moz-do-not-send="true"
              href="mailto:dpal@redhat.com" target="_blank">dpal@redhat.com</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div class="im">On 02/12/2013 12:42 PM, It Meme wrote:<br>
              > Yes - Dmitri is correct.<br>
              ><br>
              > 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.<br>
              ><br>
              > The most practical option is to continue to use the
              LDAP connectors to provision accounts to directory server.<br>
              ><br>
              > 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).<br>
              ><br>
              > 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.<br>
              ><br>
              > Any gotchas foreseen with above?<br>
            </div>
            Yes. You need to be very careful. You are bypassing all the
            checks that<br>
            framework creates around user and group management. It is
            also unclear<br>
            how the system would react to the half baked user. It is all
            doable but<br>
            you shift the risk from the tweaking core product code to
            creating a<br>
            custom IPA code. IMO the level of risk is nearly the same.<br>
            <div class="HOEnZb">
              <div class="h5"><br>
                > 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.<br>
                ><br>
                > Thank you for your help, insights, input - they are
                very helpful and greatly appreciated.<br>
                ><br>
                > On 2013-02-10, at 7:32, Dmitri Pal <<a
                  moz-do-not-send="true" href="mailto:dpal@redhat.com">dpal@redhat.com</a>>
                wrote:<br>
                ><br>
                >> On 02/09/2013 11:53 AM, John Dennis wrote:<br>
                >>> On 02/08/2013 05:29 PM, It Meme wrote:<br>
                >>>> Hi:<br>
                >>>><br>
                >>>> Scenario:<br>
                >>>><br>
                >>>> 1) User is created via LDAP call to IPA
                (i.e.the 389 Directory Server)<br>
                >>>><br>
                >>>> The above user will not have
                IPA-specific attributes.<br>
                >>>><br>
                >>>> Can we use the Python Library, or CLI,
                to modify the account to<br>
                >>>> IPA-ize it?<br>
                >>> You're really better off using the IPA API
                directly rather than trying<br>
                >>> to bypass it. Why? Because we implement
                additional logic inside the<br>
                >>> commands. If you could achieve everything
                IPA does by just modifying<br>
                >>> an LDAP server there wouldn't be a need for
                IPA. A good example of<br>
                >>> this is group membership, some of that
                logic is handled directly by a<br>
                >>> plugin to the 389 DS, but a large part of
                it is implemented in the IPA<br>
                >>> commands that manage users and groups. You
                really don't want to bypass<br>
                >>> it.<br>
                >>><br>
                >>> You have a number of options on how to call
                the IPA commands:<br>
                >>><br>
                >>> 1) the ipa command line client<br>
                >>><br>
                >>> 2) sending the command formatted in JSON to
                the server<br>
                >>><br>
                >>> 3) sending the command formatted in XML-RPC
                to the server<br>
                >>><br>
                >>> 4) calling the command from your own python
                code<br>
                >>><br>
                >>> 5) using the web GUI<br>
                >>><br>
                >>> It's really not hard to call the IPA
                command line client from a<br>
                >>> program, typically this is done via a
                "system" command of which there<br>
                >>> are a number of variants.<br>
                >>><br>
                >>> The following thread has a discussion of
                how to invoke one of our<br>
                >>> commands from Python code, this particular
                email response from Martin<br>
                >>> shows how it can be done in in about half a
                dozen lines of code.<br>
                >>><br>
                >>> <a moz-do-not-send="true"
href="https://www.redhat.com/archives/freeipa-users/2012-June/msg00334.html"
                  target="_blank">https://www.redhat.com/archives/freeipa-users/2012-June/msg00334.html</a><br>
                >>><br>
                >>> What I'm not understanding why you're
                avoiding using the commands we<br>
                >>> provide. If you're not familiar with how to
                call another<br>
                >>> program/process we can help you or just
                google it. Or is the problem<br>
                >>> your existing management system does not
                provide you with any "hooks"<br>
                >>> to execute code when an action occurs. But
                from everything you've said<br>
                >>> so far you imply it does provide such
                hooks. Perhaps if you could be<br>
                >>> more specific we could be more helpful.<br>
                >> It seems that the management system in question
                can insert an entry into<br>
                >> LDAP but can't do the "generic" hook.<br>
                >> I bet this is the issue here.<br>
                >><br>
                >><br>
                >> --<br>
                >> Thank you,<br>
                >> Dmitri Pal<br>
                >><br>
                >> Sr. Engineering Manager for IdM portfolio<br>
                >> Red Hat Inc.<br>
                >><br>
                >><br>
                >> -------------------------------<br>
                >> Looking to carve out IT costs?<br>
                >> <a moz-do-not-send="true"
                  href="http://www.redhat.com/carveoutcosts/"
                  target="_blank">www.redhat.com/carveoutcosts/</a><br>
                >><br>
                >><br>
                >><br>
                >> _______________________________________________<br>
                >> Freeipa-users mailing list<br>
                >> <a moz-do-not-send="true"
                  href="mailto:Freeipa-users@redhat.com">Freeipa-users@redhat.com</a><br>
                >> <a moz-do-not-send="true"
                  href="https://www.redhat.com/mailman/listinfo/freeipa-users"
                  target="_blank">https://www.redhat.com/mailman/listinfo/freeipa-users</a><br>
                <br>
                <br>
                --<br>
                Thank you,<br>
                Dmitri Pal<br>
                <br>
                Sr. Engineering Manager for IdM portfolio<br>
                Red Hat Inc.<br>
                <br>
                <br>
                -------------------------------<br>
                Looking to carve out IT costs?<br>
                <a moz-do-not-send="true"
                  href="http://www.redhat.com/carveoutcosts/"
                  target="_blank">www.redhat.com/carveoutcosts/</a><br>
                <br>
                <br>
                <br>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
<a class="moz-txt-link-abbreviated" href="http://www.redhat.com/carveoutcosts/">www.redhat.com/carveoutcosts/</a>


</pre>
  </body>
</html>