Talking about Samba4, Active Directory and LDAP

Development
1

[quote=“robb, post:10, topic:690, full:true”]
@Christian
With NS 7 we aim to add Samba4+Kerberos to the services and this will bring the functionality closer to a Windows AD server, and probably closer to Univention functionality. Although I can not tell exactly what it would take since I am not an LDAP/AD/Samba4 expert as you are… :slight_smile:[/quote]

I would not say I’m an expert :mask: well, perhaps on LDAP :wink:

Indeed bringing Kerberos in is definitely a great step ahead especially if other embedded components benefit from this SSO feature. As you stated in another post, it’s all matter of “company size” thus scenario. If you bring Kerberos for small company which may not have a lot of computer, perhaps even not “Windows pro” workstations, then Kerberos is pretty useless because login/password will still be used and domain concept, if we discuss about Windows, doesn’t bring, IMHO, a lot of added value here.

On the other hand, as soon as you expand either scope (more clients, pro Windows workstation or whatever client supporting Kerberos) + admin capability to understand what’s behind, then this is another game: Kerberos, although not perfect will greatly change the way internal (I mean “within the company LAN”) authentication works. Add another external server/application, join Kerberos domain and here you are with SSO and somewhat better security.

Once you’re there, if your Kerberos implementation is Samba4, then you’re are very close to emulate Windows domain.

As you know, this is not as easy as it looks first because Samba team had to make some choices in term of internal design. Like Microsoft, they do maintain their own dedicated LDAP server which can’t really be used as “your” LDAP server for other purposes. One can’t (yet?) customize schema thus solution is to have internal synchronization (I wont write replication) with your LDAP sever, keep Samba LDAP for pure Samba/domain stuff and expose and use your own LDAP for anything else.

Does it mean this is useful only for company with Windows pro clients especially because of GPOs? I’m not so sure but there is room for further debate, for sure :sunglasses:

1 Like
2

Yep for now the decision to make, either openldap or samba4 drives some headaches to the developer.

If the pam authentication through apache is easy, when you must authenticate by ldap (openldap or samba4) for sogo by example, the skill level must grow quickly…no much howtos or examples. I will have the same issue with dokuwiki soon.

Sure a syncronisazion beetween the two ldap would be nice

3

[quote=“stephdl, post:12, topic:690, full:true”]
Yep for now the decision to make, either openldap or samba4 drives some headaches to the developer.[/quote]

Unfortunately, unless plan is to support LDAP without any customization but only what Samba would or may provide, there is no debate neither choice: both are required and synchronization is mandatory.

[quote=“stephdl, post:12, topic:690, full:true”]
If the pam authentication through apache is easy, when you must authenticate by ldap (openldap or samba4) for sogo by example, the skill level must grow quickly…no much howtos or examples. I will have the same issue with dokuwiki soon.[/quote]

That’s an interesting point :wink:

1 - I don’t really understand why, except for testing purpose, one would like to authenticate “locally” from service running on whatever server as soon as this service is exposed to significant number of users. This would mean to maintain accounts locally and also mean that no external application can access this list of accounts (of course I do understand that PAM means potentially pam_ldap, pam_krb5 etc…

2 - Despite what it looks like, LDAP is a very easy protocol (that’s why I feel like an expert :yum:). what might be potentially difficult (although most of the time it’s not) is to decide if you want to authenticate at application level or at middleware level.
e.g. here you may want to delegate authentication to Apache server itself which will handle authentication and grant access to whatever content behind (depending on conf of course).
But you may also not implement any access control, meaning no authentication at Apache level, access your application and handle authentication in your PHP code, f.i.

I configured Dokuwiki few month ago to rely on LDAP. I’ll revert back to you later this week-end with some hints :sunglasses:

1 Like
4

Nice to have a second brain to resolve issues but my concern is to authenticate in a webapp with openldap or the samba4 ldap. Actually you cannot have the two installed at the same time.

I know how to authenticate with ldap and apache, now with pam and apache(I wrote some notes http://wiki.nethserver.org/doku.php?id=developer:authentication_through_apache).

However when you need to autenticate an app through samba4 the shemas is not the same…maybe i can use the same than sogo https://github.com/NethServer/nethserver-sogo/blob/master/root/etc/e-smith/templates/etc/sogo/sogo.conf/45user_source

I don’t have tried yet for nethserver-dokuwiki…but we just fear what we don’t know :slight_smile:

5

I’m not an an expert, but I’ve understood that SSSD/PAM is the “thing” to talk with for user related matters.
The app don’t need to know where users live.
@davidep, am I wrong?

1 Like
6

Sadly, it depends on the app requirements. Wherever possible, we configure an application to authenticate with PAM and read users with glibc. Those components provide (through sssd) an abstraction layer against different backends. We have AD and OpenLDAP. This is easy.

When not possible, the application must be configured to access the backend directly and support all possible scenarios: local AD, local OpenLDAP, remote AD, remote OpenLDAP. This is complex.

7

Why would it be more complex to define in you application LDAP settings that have already been defined, BTW, in SSSD (or directly in NSS if not Redhat/CentOS).
LDAP configuration doesn’t change that much and SSSD provides, to me, only the redirection (plus some caching etc… but this it out of scope in this debate)

Furthermore, there is something one needs to take in account:

  • PAM deals with authentication only, and when authentication directly done through PAM, it assumes RFC2307 (bis if any) has been deployed and configured in LDAP. (RFC2307 is NIS like implementation in LDAP)
  • Then profiling is based, at best, still when using SSSD, on RFC2307 attributes or group membership, meaning you don’t access LDAP directly here but through abstraction layer assuming that you look for POSIX account which may be stored either in LDAP or in local file or elsewhere, it doesn’t matter and that’s really where this approach does help and shine.

On the other hand, if your application needs to rely on different attributes (well, say mailaddress :slight_smile:), PAM doesn’t help because PAM = authentication, and SSSD doesn’t neither. Your mail server will have to access LDAP server directly.

Sure you may have specific SSSD implementation but principle remains the same.

To make it short, in closed “Redhat/FreIPA” local implementation, everything looks like to work through SSSD but as soon as you need to do something really relying on LDAP as directory provider (I mean aside authentication and basic group membership), I don’t understand how it could work without telling your application where LDAP server is, where to look at and which attributes to use. Did I say this is complex? no, to me it’s not even if it requires some basic (very basic) training

8

[quote=“stephdl, post:14, topic:690, full:true”]
Nice to have a second brain to resolve issues but my concern is to authenticate in a webapp with openldap or the samba4 ldap. Actually you cannot have the two installed at the same time.[/quote]

Of course you can… but not running on same port :yum:
but why would you want to authenticate against one or the other? schema differs, of course because Samba team faces same constraints as Microsoft with AD (especially because goal is to mimic AD): i.e. schema is not flexible and is almost AD-like

Thus you have to decide which directory fits best for you if you have both (I mean both synchronized)

9

Like the Z implementation used to have before cutting out openldap.

10

Sure and like Univention currently does. It’s not rocket science: servers do not listen on same ports, that’s it.
However, synchronizing directories is another story.

11

Actually after the installation you need to install either nethserver-directory (openldap) or nethserver-dc(samba4) which conflict each other.

My role is not to decide that my module needs openldap or samba4( once said it will be easier for me to decide to go with openldap), it is to check which ldap is installed and accordingly do the application setting.

Sure a ldap synchro is the way i dream but it doesn’t exist yet

12

OK, this is much clearer now :slight_smile:
So you don’t have both in parallel (if I can say so) but you also won’t have same schema… thus you need to need to prepare 2 different configuration templates.
Do you mean that if you decide to install either directory or DC, there is no place in Nethserver conf storing this information for purpose like the one we discuss? (sorry for my silly question but for the time being, I didn’t install NS yet)
If problem is only “to check”, then this is pretty easy: as schema differs, you could, f.i. just check whenever you find specific Samba entry like dnszone or similar stuff. However, this would require to authenticate because anonymously, you should not see anything. And as you don’t know which one you target, you don’t know yet how to authenticate… :grin:

However, if you look at Root DSE, it will tell “where” you are :wink:
Samba 4 will expose “samba team” in the VendorName attribute

13

This information is available from esmith config DB, under the sssd key. @giacomo wrote a small Perl module with common functions for cfg templates and actions.

2 Likes
14

Yo folks,

Getting some clarification from stepfd!, I understand better his question but then this opens room for further discussions and debate about this “ldap vs. Samba 4” design choice. Most likely aspects you already discussed in the past, I didn’t search this forum…:flushed:

What I told to Stephane is that both LDAP and S4-LDAP (if we say that S4-LDAP stands for the "AD like LDAP deployed by Samba 4) allow external applications authentication using LDAP protocol, both being LDAP servers. However, obviously, schema differs and this also impacts the way applications are accessing it.

What makes me react and initiate this answer is the strategy behind use of Samba4:

  • there is no debate: not offering Samba4 support would be a wrong idea. All competitors do it already :confused:
  • Samba4 means Windows DC (and AD like LDAP back-end) which is useful only if your workstations are Windows pro (to authenticate against Windows domain) or if you decide to rely on Kerberos clients. Any other good reason I don’t perceive here ?
  • S4-LDAP is, like AD, not flexible. It will support some external applications but in case you need to customize schema, then it will not be supported, which strongly limits its scope.
  • On the other hand, standard LDAP server (OpenLDAP) is flexible, permits external applications to rely on it for authentication and more (including Samba…)

Having to decide whether LDAP server do be deployed in NS is Ldap or S4-LDAP means that all “internal” applications have to maintain 2 different configurations in order to access LDAP back-end with the right setting. This is painful and doesn’t permit external applications to easily use NS LDAP server (especially if deployment includes Samba). That’s the reason why most NS competitors decide to maintain the 2 directories in parallel with sync process in the middle.
If I understand well, Samba team plans to evolve with their design as they do understand the side effect but I’m not aware of any plan (I don’t track it closely neither.

1 Like
15

Sure it is the way to go. but

  • At the installation of the other LDAP, it must copy all informations to the other LDAP
  • When Informations are changed in one LDAP, they must be written to the other.

Or another solution, a bit out of mind of the modularity of NS, it was to have only one nethserver-directory (openldap+samba4)

16

Sorry, my previous statement was perhaps not clear enough. When I wrote 2 configurations, I didn’t mean “content stored in 2 directories” but configuration, at application level, able to address either one LDAP schema or the other. Like 2 different conf and you chose the right one once you know what’s your target back-end.

Sync between the 2 directories is definitely another different topic, to be addressed once decision to support the 2 directories in parallel is made, IMHO. This is not so easy and brings lot of problems even if it, obviously get rid of the this “dual configuration” stuff.

17

Honestly @Christian, I really appreciate your statements but don’t get me wrong, I suggest you searching the forum a bit deeper and read a lot of our documentation first :blush:

We have covered those stuff in the past and many development choices are already discussed here.
Let’s get your hands dirty installing NethServer! We need specific requests and detailed suggestions :writing_hand:
Thanks again

18

As I wrote, I’ll indeed stop here my questions / debates around this topic.
I do understand now that choices have been discussed and made in the past based on what DeV team understands of technology, limitations, constraints etc…

That’s fine if this is settled. It was not clear previously but perfectly clear now. Thank you for the tile spent :wink:

1 Like
19

i do not understand the fundamentals very much, just thought this might be an option: