Re: [PLUG] Questions regarding LDAP and AD

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