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.
How can we improve it?
I agree! Wherever possible we ought to automate the configuration steps.
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. 
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
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.
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.
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.
seems good for me…this credentials could be saved somewhere to be accessible by the template system file ?
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.
…furthermore, existing applications should not be changed if they rely on NethServer::SSSD!
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
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 
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.
Feature released in
