Re: [PLUG] Questions regarding LDAP and AD

On Thu, Sep 22, 2016 at 2:59 PM, Morgan Jones <morgan@morganjones.org> wrote:

I’m just seeing this thread and it sounds like you may be on your way to a solution but I’ll add that I have a few clients happily using an older version of 389. One implementation in particular authenticates for ~200 hosts via sssd but also email and a host of disparate applications. We’ve seen our share of bugs and quirks but it’s been largely solid. One concern we have is the community feels a little small and largely supported by Redhat engineers on the mailing list.

Have you looked at OpenLDAP? It has a huge community and based on the LDAP conference I attended in the fall seems to have a lot of the non-AD ldap space. The mailing list can be curt and in some cases disappointing insulting.

I can’t comment on AD except to say we regularly run into SAAS and on-prem products that support AD out of the box but need integration to work with 389.

389 at least used to have an AD sync tool. We got it working as proof of concept—it was not without significant quirks but it did work. We haven’t looked at it in a few years.

Did you decide to implement on AD and how is it going?

-morgan

On Sep 21, 2016, at 14:28, Tone Montone <tonemontone@gmail.com> wrote:

Joe,

Yep. I was able to use both nss and pam, and nds and sssd. I was also able to switch from 389-ds to Active Directory. Hardest part was ssl configurstions and port 636.

Thank you

Sent from my iPhone

On Sep 21, 2016, at 12:49 PM, Joe Rosato <rosatoj@gmail.com> wrote:

Getting late into this but have you looked at sssd?
https://fedorahosted.org/sssd/wiki/HOWTO_Configure
Joe

On Thu, Sep 8, 2016, 10:13 PM Tone Montone <tonemontone@gmail.com> wrote:
Chris,

Yes, local accounts still work. They are controlled and prioritized via /etc/nsswitch.conf.

e.g.

passwd: files ldap
shadow: files ldap
group: files ldap

The system checks files (/etc/passwd and /etc/shadow) first, then if not found looks to ldap. This could also be sssd, nis, etc.

Mike

On Thu, Sep 8, 2016 at 8:10 PM, Christopher Barry <christopher.r.barry@gmail.com> wrote:
On Thu, 8 Sep 2016 11:37:04 -0400
Tone Montone <tonemontone@gmail.com> wrote:

>Update:
>
>I was able to get a 389 server up and running and have LDAP clients
>authenticate to it. However, before I was able to have the Active
>Directory server sync to it, someone recommended skipping the 389 or
>FreeIPA server altogether and point directly to AD. After some
>additional configuration on the AD side, this worked for me.
>
>First, ensure the times are synchronized across all systems. i.e.
>Make sure NTP and AD use the same time server. This is more an issue
>with Kerberos than LDAP, but it did cause issues for me until it was
>resolved.
>
>Second, install Identity Management for UNIX Components on the AD
>server. This provided attributes to support Unix systems.
>
>Third, the configuration requires a bind user on the AD side, in order
>for the LDAP client to logon and retrieve shadow password information;
>
>Overall it was fairly easy to configure and install, once I found the
>commands to test configurations, which logs contained the error
>information I need to troubleshoot issues, debug commands, etc; I was
>using SSL certificates in this configuration so some of the hurdles
>were SSL/TLS related.
>
>PROS: One centralized password management.
>
>CONS: You may lose control over account management if your admin teams
>are split between operating systems.
>

But, local *NIX user/passwords are still honored on each box, correct?
Meaning, root or youasadmin can be locally authenticated.

>Some additional tasks I am working on:
>
>1. Use LDAP for sudoers administration.
>2. Use LDAP for ssh public key storage for logons.
>
>Thanks to all for any and all information provided, it was an
>interesting journey.
>
>Mike
>
>On Tue, Sep 6, 2016 at 11:53 AM, Keith C. Perry
><kperry@daotechnologies.com> wrote:
>
>> I wanted to circle back around to this since I think I've make some
>> inroads into understanding the current state of affairs....
>>
>> It appears there is no "clean" (i.e. a FOSS solution relatively easy
>> to install, build and manage) Linux distro agnostic way to replace
>> Active Directory in situations where you need to manage identities
>> and resources for Linux clients and AD clients. There are two major
>> issues at play in this regard:
>>
>> 1) Samba 4's AD DC functionality is based on included LDAP and
>> Kerberos functionalities which are not modular. They MUST be used
>> if Samba 4 is to function as a replacement for Active Directory.
>> Therefore, the LDAP and Kerberos services from FreeIPA can not be
>> directly used with Samba 4.
>>
>> https://wiki.samba.org/index.php/Setup_a_Samba_Active_
>> Directory_Domain_Controller
>>
>> *"Please note that you do not need to install or configure a separate
>> Kerberos KDC for Samba to work. Samba includes an AD compatible KDC,
>> currently based on an included copy of the Heimdal project. Likewise
>> Samba ships its own LDAP implementation for AD backends. OpenLDAP or
>> other LDAP servers are not supported at the moment."*

>>
>> 2) FreeIPA's focus is on Linux and other standards based environments
>> (including other Unix systems... https://www.freeipa.org/page/
>> ConfiguringUnixClients) and thus it is NOT a replacement for Active
>> Directory. FreeIPA does a good job of providing an integrated
>> solution for identity management which can provide service
>> authorizations via kerberos ticketing and other principals. It does
>> not provide the actual user service (e.g. CIFS for Windows file
>> sharing) but it does take care of things NTP, DNS, PAM modules and
>> other critical services needed to authenticate in an AD like manner.
>>
>> https://www.freeipa.org/page/Windows_authentication_against_FreeIPA
>>
>> What about domain trusts?
>>
>> Recent versions of FreeIPA (>= v4.x.x) allow for domain trusts. By
>> using domain trusts, it would be possible to have FreeIPA and Active
>> Directory realms trust each other so users in either domain have
>> access to resources seamlessly across both domains. This does not
>> address the issue in #1 above but is something that both projects
>> are aware of and want to solve. As I understand it, the biggest
>> problem is getting MIT Kerberos to work as an embedded KDC for Samba
>> 4. There are various discussions on that as well as other items
>> that need to be addressed.
>>
>> https://www.freeipa.org/page/IPAv3_Architecture
>> https://wiki.samba.org/index.php/Samba4/Proposal_for_IPA_
>> to_AD_forest_trust
>>
>> Where that leaves us is:
>>
>> 1) If you just are managing identities for Linux servers or need a
>> standards based directory for authorizations, FreeIPA is worth a
>> look. Even though it is thought of as a Red Hat product, all my
>> testing was done on Ubuntu 16.04 LTS with the FreeIPA packages that
>> are available (4.3.1 as of this email). It worked as expected the
>> only thing I had to do is manually edit the PAM configuration
>> (literally adding 1 line) so that home directories are created for
>> accounts that do not exist. I did not test it but adding client
>> servers should simply be a matter of running "ipa-client-install
>> --mkhomedir" on a realm member server with minor tweaks, if any, for
>> your platform (such as on Ubuntu, PAM).
>>

>> 2) If you need to manage identities for Linux *and* Windows users
>> *and* you don't want an Active Directory server in the mix then your
>> only bet for now is Samba 4 AD DC. You have to keep in mind that
>> you will still need other critical services like NTP, DNS, DHCP,
>> etc. You will probably also want some sort of GUI interface for
>> user management (SWAT2, Webmin, GAdmin, etc... see
>> https://www.samba.org/samba/GUI/... most of these seem to be for
>> Samba 3). Not an impossible job but the breadth of what you have to
>> do manually is why projects like Zentyal are very attractive.
>>
>> Once Samba 4 can use other LDAP and Kerberos services, using FreeIPA
>> with Samba or doing a domain trust between FreeIPA and a Samba AD DC
>> will become options. Hopefully that is not too far away. You may
>> have noticed from
>> https://www.freeipa.org/page/Windows_authentication_against_FreeIPA
>> that supposedly Samba 4.3 is able to do cross realm trusts. This
>> feature is stated as incomplete and I did not have any success
>> configuring the 4.3.9 Samba server that comes with Ubuntu 16.04 LTS
>> to use FreeIPA 4.3.1. This probably is because Samba 4 needs to be
>> built differently (see
>> https://www.freeipa.org/page/IPAv3_AD_trust#Samba). This is also
>> confusing because such a build also implies having Samba *without
>> *AD DC capabilities (i.e. you're building at Samba 3 server with
>> Samba 4 client, see
>> https://lists.samba.org/archive/samba-technical/2012-May/083913.html)
>> so I don't see how you can or would use trusts (unless its to an MS
>> AD?). If I am misunderstanding that, I'd enjoy hearing some feedback
>> on how this is done.
>>
>>
>> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
>> Keith C. Perry, MS E.E.
>> Owner, DAO Technologies LLC
>> (O) +1.215.525.4165 x2033
>> (M) +1.215.432.5167
>> www.daotechnologies.com
>>
>> ------------------------------
>> *From: *"Keith C. Perry" <kperry@daotechnologies.com>
>> *To: *"Philadelphia Linux User's Group Discussion List" <
>> plug@lists.phillylinux.org>
>> *Sent: *Thursday, August 25, 2016 1:22:17 PM
>> *Subject: *Re: [PLUG] Questions regarding LDAP and AD

>>
>> I'm in the middle of designing a solution for this for a client that
>> is using Zentyal but hasn't been happy with how feature seem to have
>> been disappearing in recent releases. We're concerned about their
>> strategy and getting caught off guard because of issues with MS
>> being involved.
>>
>> That said, I was looking at ApacheDS but that was a bit messy and
>> didn't feel like it was ready for prime time.
>>
>> With Fedora Server, FreeIPA supposedly can managed from Cockpit but
>> even the UI on Fedora 24 Server is not showing the proper
>> components. Still, we're leaning that way because FreeIPA + Samba 4
>> would be a complete solution.
>>
>> The problem there is that no one has confidence in Fedora Server
>> staying stable enough for production so I'm rebuilding in Ubuntu
>> since FreeIPA is available in 16.04 LTS. Samba 4 of course is but
>> Cockpit is less so. Its also less critical but it would be nice. I
>> might just compile it if its not too big a deal.
>>
>> Not the most fun I've ever had but there needs to be a real
>> alternative to Zentyal.
>>
>> To that end, in anyone knows someone close to the Zentyal folks.
>> I'd love to hear from them in regards to their future strategy and
>> how much control or involvement does Microsoft really have.
>>
>> ---
>> KP-
>>
>> On Aug 25, 2016 12:38 PM, Tone Montone <tonemontone@gmail.com> wrote:
>>
>> Hello,
>> I have an implementation question regarding LDAP and AD.
>>
>> I am looking for advice on a path forward for managing user accounts
>> across about 500 Unix systems, which are comprised of a mixture of
>> RHEL 5 and 6, and Solaris 10 and 11; There is also some OEL, which
>> is basically RHEL 5, and some Suse sprinkled in. Currently, we are
>> using local accounts, and I would like to move to a more
>> streamlined/centralized method.
>>
>> I need a solution that has a support package tied to it, as it's for
>> a government installation and that is a mandatory requirement.
>>
>> I was thinking about using Red Hat Directory Server, which is
>> basically 389-DS. Having the AD server do a one-way sync to the DS,
>> then have all the Unix systems point to the DS. However, I read
>> that in some instances you can have systems point directly to AD
>> servers and get their authentication directly from the AD, so you
>> don't need an LDAP intermediate server, but I am not sure it will
>> work for all systems/OSes. e.g. I read that you could use RHEL's
>> IdM (Identity Manager) on RHEL 6, but I don't think this will work
>> on RHEL 5.
>>
>> I also thought about using LDAP for sudoers file management, as well
>> as storing ssh public keys.
>>
>> I installed 389-DS to do some testing, and I also looking at FreeIPA
>> because it provides Kerberos, as well as Samba.
>>
>> Any advice or experience anyone would like to share would be greatly
>> appreciated.
>>
>> Thanks,
>>
>> Mike
>>
>>
>>
>> I'm in the middle of designing a solution for this for a client that
>> is using Zentyal but hasn't been happy with how feature seem to have
>> been disappearing in recent releases. We're concerned about their
>> strategy and getting caught off guard because of issues with MS
>> being involved.
>>
>> That said, I was looking at ApacheDS but that was a bit messy and
>> didn't feel like it was ready for prime time.
>>
>> With Fedora Server, FreeIPA supposedly can managed from Cockpit but
>> even the UI on Fedora 24 Server is not showing the proper
>> components. Still, we're leaning that way because FreeIPA + Samba 4
>> would be a complete solution.
>>
>> The problem there is that no one has confidence in Fedora Server
>> staying stable enough for production so I'm rebuilding in Ubuntu
>> since FreeIPA is available in 16.04 LTS. Samba 4 of course is but
>> Cockpit is less so. Its also less critical but it would be nice. I
>> might just compile it if its not too big a deal.
>>
>> Not the most fun I've ever had but there needs to be a real
>> alternative to Zentyal.
>>
>> To that end, in anyone knows someone close to the Zentyal folks.
>> I'd love to hear from them in regards to their future strategy and
>> how much control or involvement does Microsoft really have.
>>
>> ---
>> KP-
>>
>>
>> On Aug 25, 2016 12:38 PM, Tone Montone <tonemontone@gmail.com>
>> wrote:
>> >
>> > Hello,
>> >
>> > I have an implementation question regarding LDAP and AD.
>> >
>> > I am looking for advice on a path forward for managing user
>> > accounts
>> across about 500 Unix systems, which are comprised of a mixture of
>> RHEL 5 and 6, and Solaris 10 and 11; There is also some OEL, which
>> is basically RHEL 5, and some Suse sprinkled in. Currently, we are
>> using local accounts, and I would like to move to a more
>> streamlined/centralized method.
>> >
>> > I need a solution that has a support package tied to it, as it's
>> > for a
>> government installation and that is a mandatory requirement.
>> >
>> > I was thinking about using Red Hat Directory Server, which is
>> > basically
>> 389-DS. Having the AD server do a one-way sync to the DS, then have
>> all the Unix systems point to the DS. However, I read that in some
>> instances you can have systems point directly to AD servers and get
>> their authentication directly from the AD, so you don't need an LDAP
>> intermediate server, but I am not sure it will work for all
>> systems/OSes. e.g. I read that you could use RHEL's IdM (Identity
>> Manager) on RHEL 6, but I don't think this will work on RHEL 5.
>> >
>> > I also thought about using LDAP for sudoers file management, as
>> > well as
>> storing ssh public keys.
>> >
>> > I installed 389-DS to do some testing, and I also looking at
>> > FreeIPA
>> because it provides Kerberos, as well as Samba.
>> >
>> > Any advice or experience anyone would like to share would be
>> > greatly
>> appreciated.
>> >
>> > Thanks,
>> >
>> > Mike
>>
>>
>> ____________________________________________________________
>> _______________
>> Philadelphia Linux Users Group --
>> http://www.phillylinux.org
>> Announcements - http://lists.phillylinux.org/
>> mailman/listinfo/plug-announce
>> General Discussion -- http://lists.phillylinux.org/
>> mailman/listinfo/plug
>>
>>

--
Regards,
Christopher

___________________________________________________________________________
Philadelphia Linux Users Group -- http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug

___________________________________________________________________________
Philadelphia Linux Users Group -- http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug

--
Joe

___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion --   http://lists.phillylinux.org/mailman/listinfo/plug
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion --   http://lists.phillylinux.org/mailman/listinfo/plug

___________________________________________________________________________
Philadelphia Linux Users Group -- http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug