Special account for applications with simple LDAP bind

[stephdl]

Release of NethServer 7.4.1708 Final

I think we should stop to use the machine password to browse Samba AD LDAP and always require a dedicated account, like we do with MS AD. Local AD provider can generate it automatically.

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.

[davidep]

Release of NethServer 7.4.1708 Final

I’m not sure but I fear a time bomb for all web applications with ldap bind…in a really short time

How can we improve it?

Release of NethServer 7.4.1708 Final

manual actions are not good (from my point of view)

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

[giacomo]

Release of NethServer 7.4.1708 Final

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

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.

[stephdl]

Release of NethServer 7.4.1708 Final

How can we improve it?

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

[davidep]

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…

[stephdl]

Release of NethServer 7.4.1708 Final

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…

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

[davidep]

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.

[stephdl]

yes, it could be documented and well known by everybody

[davidep]

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.

[stephdl]

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

[giacomo]

Just for our curiosity, what is your solution

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.

On a local accounts provider installation we can replace the existing machine credentials with a new dedicated identity which is created automatically once

Totally agree!

.this credentials could be saved somewhere to be accessible by the template system file ?

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

[davidep]

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

[stephdl]

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

YES YES YES

[giacomo]

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

[davidep]

new dedicated identity

I’m experimenting with “userWorkstations” LDAP attribute:

• https://msdn.microsoft.com/en-us/library/ms680868(v=vs.85).aspx
• https://msdn.microsoft.com/en-us/library/ms677943(v=vs.85).aspx

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]

What do you think?

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

[davidep]

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.

[davidep]

Feature released in

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