Special account for applications with simple LDAP bind

activedirectory
accounts-provider

(Stéphane de Labrusse) #1

looking for this @dev_team , I’m not sure but I fear a time bomb for all web applications with ldap bind…in a really short time. what did you suggest, create a dedicated user and use it to bind the ldap, manual actions are not good (from my point of view)

actually with ns7.4 i can see new install with sogod services crashes, and probably soon some fun with webtop.


Release of NethServer 7.4.1708 Final
(Davide Principi) #2

How can we improve it?

I agree! Wherever possible we ought to automate the configuration steps.


(Giacomo Sanchietti) #3

WebTop should be already fixed, but I agree with you we could encounter some troubles.

I have a suggestion to workaround the problem at least for Samba AD, but I didn’t have time to write it down on a new thread for discussion. :frowning:


(Stéphane de Labrusse) #4

I’m not expert here…I have one but i (really) don’t like it, write the password in /var/lib/nethserver/secrets in a human readable format.

Just for our curiosity, what is your solution @davidep and @giacomo


(Davide Principi) #5

By now, we are fixing broken apps… The password is generated by Samba, we cannot decide it.

The idea is a dedicated account, being it created automatically or manually. We can see it how…


(Stéphane de Labrusse) #6

Ok, this might be fixed in sogo with two db properties and eventually with a panel in nethgui.


(Davide Principi) #7

I was thinking about a unique identity, shared by all applications. Something like the “admins” key in config DB or the already existing sssd props BindUser/BindPassword.


(Stéphane de Labrusse) #8

yes, it could be documented and well known by everybody


(Davide Principi) #9

I think it shouldn’t need end-user documentation.

For a remote accounts provider we already have the UI fields and docs. Nothing changes for it, I guess.

On a local accounts provider installation we can replace the existing machine credentials with a new dedicated identity which is created automatically once, during RPM install/update. I’d choose a random user name and a random password. If possible set it hidden in Users&Groups page. The credentials should be visible in the UI, like the LDAP provider do, to cut/paste them to a remote host.


(Stéphane de Labrusse) #10

seems good for me…this credentials could be saved somewhere to be accessible by the template system file ?


(Giacomo Sanchietti) #11

I was thinking to create new credentials for each services, like we did in NS 6.

But I really like much more @davidep approach: simple and backward-compatible.

Totally agree!

Credentials will be accessible using NethServer::SSSD library, but in the end, I think we will save it under /var/lib/nethserver/secrets.


(Davide Principi) #12

…furthermore, existing applications should not be changed if they rely on NethServer::SSSD!


(Stéphane de Labrusse) #13

YES YES YES


(Giacomo Sanchietti) #14

Added to the roadmap, I hope we will work on it next week :slight_smile:


(Davide Principi) #15

I’m experimenting with “userWorkstations” LDAP attribute:

By setting the attribute to “,” the resulting account can do simple LDAP binds with AD, but still having denied access when logging in on workstations and connecting SMB shares.

What do you think? Could it be a viable implementation? /cc @quality_team @dev_team


(Giacomo Sanchietti) #16

I like it. By the way, event if the special crafted user could be used to login into workstations, it doesn’t sounds like a problem to me :wink:


(Davide Principi) #17

This feature is on testing! /cc @quality_team

https://github.com/NethServer/dev/issues/5396

The ldapservice user will be available from AD accounts provider like OpenLDAP already does.


(Davide Principi) #18

Feature released in

  • nethserver-dc-1.4.1-1.ns7.x86_64.rpm
  • nethserver-sssd-1.3.5-1.ns7.noarch.rpm