LDAP-accessible core directories are pretty much required for any
large enterprise for the forseeable future. Products like email
gateways, remote support hosts, clustered services, cloud
environments, etc. etc. all need highly available consistent user
provisioning and AAA service, and everybody's building in LDAP clients
to achieve this. You get a bomgar box or an Ironport and it wants
LDAP. If you have 250 linux/Solaris/HP-UX servers you can choose
LDAP, NIS/YP or Hesiod, but LDAP is best.
Microsoft's ADS is simply their "embraced and extended" LDAP, designed
to pull you into the Microsoft support structure forever by providing
capabilities and consistency slightly extended beyond what
RFC-compliant LDAP servers provide.
TL;DR version - if you have 400 or more employees build a core
directory with user passwords in it. If you are a Microsoft shop use
ADS and be happy, if you are not a Microsoft shop think very carefully
about letting the camel's nose into the tent.
--Charlie
On Wed, Oct 10, 2012 at 6:47 AM, Yair Zaslavsky <yzaslavs(a)redhat.com> wrote:
On 10/10/2012 12:13 PM, Itamar Heim wrote:
>
> On 10/09/2012 03:56 PM, Alan Johnson wrote:
>>
>> Thanks to Tim Hildred, I found out about the need to have a directory
>> server. Before I embark on this path, I thought I could ping the
>> community to get a since for what is common, easy, and/or available to
>> best suit our wants.
>>
>> First, what's the easiest one to setup and use? Something with a simple
>> GUI would be desirable: a webmin module perhaps?
>>
>> Most ideal would be something that is in line with our desire to move
>> towards single sign on, ultimately authenticating against Google Apps.
>> Does Google provide something supported? Is there something that can
>> proxy google apps auth to an oVirt supported protocol?
>>
>> Alternately, we have an LDAP server, but it does NOT store passwords,
>> and as such, does not provide authentication for anything. Will oVirt
>> store passwords for users created from such an LDAP service, or does
>> LDAP need to be the authority as well?
Currently oVirt code has SIMPLE and Kerberos authentication.
Queries that are not RootDSE queries must be authenticated.
>>
>> Finally, we also have NIS setup (thought we hope to get away from that
>> soon), so some means of authenticating through the systems local PAM
>> system would be the next most convenient.
>>
>> These are just thoughts and I am completely open to suggestions. Thanks
>> in advance for any input! =)
>
>
> in the future, well, everything is possible. for now, your choices are:
> freeIPA/IPA
> 389ds/RHDS
> MS AD
> Tivoli DS
>
> ovirt does not store passwords (other than for admin@internal)
>
>
>
>
> _______________________________________________
> Users mailing list
> Users(a)ovirt.org
>
http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users