SCIENTIFIC-LINUX-USERS Archives

July 2016

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
David Sommerseth <[log in to unmask]>
Reply To:
Date:
Fri, 22 Jul 2016 17:02:37 +0200
Content-Type:
text/plain
Parts/Attachments:
text/plain (63 lines)
On 22/07/16 13:22, Lars Behrens wrote:
> Am 22.07.2016 um 12:42 schrieb David Sommerseth:
>> On 22/07/16 09:45, Lars Behrens wrote:
> 
> [...IPA...]
> 
> Thank you for the details. ATM the need for having to run a server for
> IPA keeps me from using it, though I admit that the idea of centralizing
> everything is quite charming.

Agreed.  But IPA really doesn't need to run on a separate server (even
though I would highly recommend it).  I have a handful of virtual
machines at home, plus a few laptops.  Even here it was worth the effort
of adding IPA to the mix.  I've later on expanded with kdcproxy [1] to
allow Kerberos auth working against external virtual machines not having
direct access to my IPA server.  The kdcproxy stuff ships and is
installed by default in IPA on EL7.2.

[1] <https://github.com/npmccallum/kdcproxy>

And to add one more argument, IPA can also centralize SSH key
management.  So each user can upload their own SSH public keys to IPA
and they don't need to worry about managing authorized_keys files any
more.  That is of course when you log on from systems where Kerberos
have not been configured or is not suitable.  And then there is OTP
support, but that probably won't work too well with AD users.  And then
there are centralized sudo management .... it's just a lot of useful
features enforcing different policies available in IPA.

> Of course the very best would be if our AD-Gods would provide an IPA
> Server in parallel.

Yeah, I can somehow share that sentiment, but on the other hand, I am
really happy IPA is developed as a true open source project.
Considering how little resources IPA demands (compared to an AD server),
you probably won't see a reason why to blend IPA into an AD server.
Remember that IPA is Unix centric, while AD is Windows centric.  There
are quite some shared common ground, but there are also parts which are
very different.  And IPA happens to bridge IPA and AD fairly nicely
(from what I've seen in live demos).

Really, if you have resources on a box to spin up a virtual machine,
give it 16-20GB disk and 1GB RAM, and you're good to go installing IPA.
Unless you have many thousands users [2], then you will probably be just
fine with such a spec.  Install ipa-server packages on top of a minimal
SL7.2 base install and you'll be set in less than an hour.  As a
reference, in less than 2 days I migrated ~20 "unmanaged" SL/CentOS
boxes into IPA, including setting up 3 new IPA server installs with
master-master replication.

[2]
<https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/installing-ipa.html#server-hw-recomendations>


Okay, I'll try to stop now ... You should just try it, I'm quite sure
you won't regret it ;-)


-- 
kind regards,

David Sommerseth

ATOM RSS1 RSS2