3:56 p.m.
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:
1. Every machine with the same users has the same passwords
2. Maintenance jobs are run the same everywhere.
3. All Virtual Machines (regardless if they are using KVM or
VirtualBox) 'look' the same (there are 36 virtual machines - so far).
4. Any other thing that comes up.
5. 'Talk' to a virtual machine that is not Linux but has a LDAP client.
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.
Can someone give me some information?
TIA
Sandy
5:55 p.m.
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
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:
1. Every machine with the same users has the same passwords
2. Maintenance jobs are run the same everywhere.
3. All Virtual Machines (regardless if they are using KVM or
VirtualBox) 'look' the same (there are 36 virtual machines - so far).
4. Any other thing that comes up.
5. 'Talk' to a virtual machine that is not Linux but has a LDAP client.
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.
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
6:18 p.m.
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
11:21 a.m.
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
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
- 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
5:33 p.m.
On 20 Feb 2019, at 03:21, Steve Kuervers
<kuervers.sj(a)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(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
9:03 a.m.
You are correct that a CA is included in IdM. But many organizations
design their root CA as an independent device, often kept offline for
security. The IdM CA is then configured as a Sub-CA, responsible for its
own security domain. The benefit here is that the root CA can also provide
certificates to other security sub domains, like AD, or a VMware cluster.
Steve
On Tue, Feb 19, 2019, 16:34 William Brown, <wbrown(a)suse.de> wrote:
> On 20 Feb 2019, at 03:21, Steve Kuervers <kuervers.sj(a)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(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
_______________________________________________
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...
1885
days inactive
1898
days old
389-users@lists.fedoraproject.org
5 comments
4 participants
participants (4)
-
Sandra Poole -
Steve Kuervers -
Theadora Strother -
William Brown