On 8 Feb 2019, at 09:55, Theadora Strother <tstrothe(a)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(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)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.fedoraproje...
—
Sincerely,
William Brown
Software Engineer, 389 Directory Server
SUSE Labs