On 8 Feb 2019, at 09:55, Theadora Strother tstrothe@umich.edu wrote:

Hi Sandy,

It sounds like you might want to implement FreeIPA of which 389-ds is just one component. Documentation is available here: https://www.freeipa.org/page/Documentation

I don’t think that’s a good idea. Centos 6 IPA has quite a few issues, but also, it doesn’t solve their requirements ….

On Thursday, February 7, 2019, Sandra Poole sjpoole12@comcast.net wrote: I'm attempting to do something I've never done before.

When I was employed the company I worked for used Windows Active Directory and they had a staff of 8 to maintain all of that for the entire corporation. As a Linux System Admin I had access to a place in the Directory structure for Linux/Solaris/AIX servers and we kept our 'stuff' correct using a third party software.

Now that I am retired I do not have those resources. And I only have 3 Windows machines that are old and only used for the internet / email access.

My Linux environment is growing (both planned and unplanned). When I retired I was allowed to purchase several older tower servers for practically free, all I had to do was just clean off the hard drives with Data Center staff watching + $50. So I went from 2 physical machines to 8 machines with all having multiple hard drives and none less that 24 GB RAM.

I've finally gotten them running and configured with CentOS 6.10 x86_64 and using software RAID-1 or software RAID-1 and RAID-10.

What I want to do with 389-DS is to guarantee the following:

• Every machine with the same users has the same passwords

This depends what you mean by “same users”. If you mean system accounts like “apache”, then “no”.

But if the user is stored in LDAP, and you have SSSD configured on all the hosts, then the answer is 389-ds: yes, freeipa: yes

• Maintenance jobs are run the same everywhere.

This is not a directory server’s role. AD would enable this via group policy, but that’s not really true of unix.

So 389-ds: no, freeipa: no

Saying this, I would advise you to look at “ansible”. It’s a configuration management tool that would allow you to define these jobs, and ensure your servers are in that known good state.

It’s also useful for making sure your machines have correct SSSD configs so they all read from LDAP properly :)

• All Virtual Machines (regardless if they are using KVM or VirtualBox) 'look' the same (there are 36 virtual machines - so far).

389-ds: no. freipa: no

Again, this is the job of ansible and configuration management, not LDAP

• Any other thing that comes up.

I can’t guarantee that 389-ds or freeipa can solve any problem that comes up dynamically sadly. We do have limited project scopes :)

Ansible again, can help with this though, as you can then quickly patch, deploy changes etc…

• 'Talk' to a virtual machine that is not Linux but has a LDAP client.

389-ds: yes, freeipa: yes.

What I can't seem to locate is a tutorial or some other document that explains to a layman how to migrate users, passwords, and configuration information into my recently installed 389-DS.

LDAP is horrendous like this historically. Our latest versions on fedora 29+, and soon SUSE leap 15 have integrated and in built tools for this process.

FreeIPA however does a better job here. They have a cli and webui that allows user and group management.

If you choose to go the FreeIPA route, I have advice on this matter so you get the “best” experience possible.

I hope this helps,

Can someone give me some information?

TIA

Sandy

-- Theadora Strother Systems Administrator Senior Information Technology Services University of Michigan-Dearborn 19000 Hubbard Drive, 238 FCN Dearborn, MI 48126

---

389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....

— Sincerely,

William Brown Software Engineer, 389 Directory Server SUSE Labs

On 20 Feb 2019, at 03:21, Steve Kuervers kuervers.sj@gmail.com wrote:

Sandy, I'm a fan of your suggested FreeIPA implementation, but some real planning is required ahead of time.

You need to dig into the documentation and look at what your real requirements are. I'd suggest you plan yourself with something similar to this:

root CA - CentOS 7.x with 389-directory server and dogtag-pki CA configuration (may not be necessary depending on your requirement)

• this can be kept offline and secure

I would advise *not* using the CA functionality in IPA, and just bringing in p12 bundles instead. You could automate this with let’s encrypt or other CA that you may use.

two or more identity management servers setup to replicated- Centos 7.x with IdM installed (IdM is part of the baseline install for CentOS

I've successfully used IdM to support an ovirt virtualization cluster, and I'm told that IdM to Windows AD is relatively painless (but have not done it myself).

Clients - IdM will support Fedora, CentOS 6 and CentOS 7 clients, plus all kinds of other capabilities

Built this way, you will look a lot like the Redhat upstream solution, and you can even use the upstream documentation to plan

• Root CA = RHEL 7 Redhat Certificate Server on Redhat Directory Server

The CA is part of IDM, not seperate.

• IdM servers = RHEL 7 servers with IdM
• ovirt virt cluster = Redhat Enterprise Virtualization

Your actual Root CA, IdM servers and test clients can even exist within the ovirt cluster as clients.

Steve _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....

— Sincerely,

William Brown Software Engineer, 389 Directory Server SUSE Labs