<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 22, 2017 at 9:02 PM, Michael Ströder <span dir="ltr"><<a href="mailto:michael@stroeder.com" target="_blank">michael@stroeder.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Iulian Roman wrote:<br>
> On Wed, Feb 22, 2017 at 6:03 PM, Michael Ströder <<a href="mailto:michael@stroeder.com">michael@stroeder.com</a><br>
</span><span class="">> <mailto:<a href="mailto:michael@stroeder.com">michael@stroeder.com</a>>> wrote:<br>
><br>
>     Iulian Roman wrote:<br>
>     > On Tue, Feb 21, 2017 at 4:31 PM, Rob Crittenden <<a href="mailto:rcritten@redhat.com">rcritten@redhat.com</a> <mailto:<a href="mailto:rcritten@redhat.com">rcritten@redhat.com</a>><br>
</span><span class="">>     > <mailto:<a href="mailto:rcritten@redhat.com">rcritten@redhat.com</a> <mailto:<a href="mailto:rcritten@redhat.com">rcritten@redhat.com</a>>>> wrote:<br>
>     ><br>
>     >     Iulian Roman wrote:<br>
</span><span class="">>     >     > Does anybody know if the rfc2307aix schema is supported in IPA server<br>
>     ><br>
</span><span class="">>     >     No, it isn't supported (it's the first I've ever heard of it). Looking<br>
>     >     at the schema I doubt it is something that would ever be fully supported.<br>
>     ><br>
>     > is there any possibility to extend the existing schema with additional<br>
>     > attributes/object<br>
><br>
>     Do you really use this specific AIX schema?<br>
>     If yes, which attributes for which purpose?<br>
><br>
> I do need the aixAuxAccount and aixAuxGroup object classes . they implement some<br>
> password restrictions needed for security/compliance<br>
<br>
</span>Password policy is something best enforced centrally in the authentication server and<br>
password management system. So IMHO this serves as perfect example for proprietary<br>
attributes you won't need.<br>
<br>
How is authentication done? SSH keys, Kerberos, LDAP simple bind?<br></blockquote><div><br>Kerberos <br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> +  some other security related attributes.<br>
> Personally i do not consider them a must - they are rather some nice to have features  -<br>
> but i have to migrate an environment which does use them. And i would like as well to<br>
> make the migration as transparent as possible (therefore without "missing features").<br>
<br>
</span>Is the existing environment also an LDAP server with this particular AIX schema?<br></blockquote><div><br></div><div>no, it is a custom/legacy  solution wich does not use LDAP but local accounts which are centrally managed.  <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Or are you trying to follow a migration path to LDAP suggested by IBM docs?<br>
<br></blockquote><div><br></div><div>no, i've adapted some freeipa document which describes the client setup for aix (in original form it does not work and it needed some modifications) , but i have to admit that the documentation for integrating unix clients is poor and incomplete . IBM does recommend  TDS, which integrates seamlessly with both AIX and Linux clients  + other features which should help in integrating in heterogeneous environment,  but i am not evaluating that solution currently (i may look into it only if i cannot integrate it with IPA in the way i want). <br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Being in your position I'd first compile a list of functional and security requirements<br>
and ask then whether these requirements can be implemented with FreeIPA. I'm curious to<br>
learn whether "some other security related attributes" are still needed after all.<br>
<br></blockquote><div>all the password restriction policies  (minage, maxage, number of characters in the password, history of the old passwords, number of characters, password dictionaries , etc) , loginretries - which "locks" the account after a number of unsuccessful logins  , hostsallow/deny login , all the ulimit related parameters (that can probably be  ignored)  .  It is not a matter if they increase the security or not or if they are really needed, but a matter of complying to some security standards agreed between two parties  . It would be easy to keep  them in the same format  than to change the security standard  , tooling and processes behind (bureaucracy , overhead and complexity of the enterprise environment makes me try to avoid that as much as possible , especially when there are many people and departments involved , with their own mindset and playing different politics). <br></div><div><br><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Ciao, Michael.<br>
<br>
</blockquote></div><br></div></div>