Hi.
I’ve already set up 389-ds to authenticate users in various web based apps (for example glpi) but I’m having some problems with setting it up to work with samba.
First I had problems with some missing object classes but I’ve found samba schema for 389-ds and imported it to my server and now it works, I can set up LDAP as password backend for samba.
Now I have another problem - adding new users do 389-ds so they would “appear” in samba. I can add users in 2 ways (AFAIK):
389-console
yast2 Users module
With 389-console there is that problem it won’t add sambaSamAccount objectclass automatically so it won’t fill the other mandatory attributes (like sambaNTPassword and sambaSID). I don’t really know how to fill them by myself
With Users module in Yast there are three problems:
setting LDAP filter would ask for bindDN which is ok but it would never authenticate in the first time. It would throw an error “Invalid credentials” and when I try for the second time with the same credential it will authenticate successfully
while LDAP filter is on pressing “Add user” button would make the window freeze for more than 1 minute (I’d dare to say it’s about 5 minutes) and after it unfreezes I can finally add a user.
creating new user would create him in base dn (dc=nordprim,dc=local) instead of ou=People,dc=nordprim,dc=local
On that server I’m using sssd to connect to ldap so here’s sssd config file. I have no idea what more I can give you to help me with those problems.
First,
You may have to describe with some detail how you’re setting up your SAMBA integration, skimming the 389-ds documentation I found only “legacy” documentation describing how to integrate with SAMBA 3 and within that a link to 3rd party documentation that supports more than just file serving (managing host machines).
As expected, you are finding that the LDAP schema has to be exact, so in the first place I’m suspicious of using tools that set up differently, and I’m also wary of tools that don’t have automatic import/replication and instead require manual configuration… There are lots of possibilities for errors and missed details when automation isn’t supported.
A general observation is that you only found the one YaST User module for configuration, the following is where the LEAP documentation for Authentication Server (ie LDAP) starts, and it describes in both this section (section 4) and the next (section 5) that you may need to configure settings in 3 different modules… the User module plus the Windows Domain and LDAP/Kerberos modules.
Personally though…
I’d look for 389-ds documentation and tools to export/integrate with SAMBA 4 supporting the features you want… And decide whether you need integration with anything else for example managing Users… Although I have a top-down instinct and philosophy about security hierarchies which means that if you’re going to use a 389-ds server to be your Authenticator/Authorizor, then you should use tools and methods for that to create and manage objects like User accounts. If YaST tools work, then that’s a happy finding, but otherwise wouldn’t be high on my list of expectations.
If 389-ds and YaST tools don’t match up perfectly, you might eventually consider a “federated” architecture where you set up not only 389-ds but also an openSUSE server possibly with separate domains… Your openSUSE clients would not authenticate directly with 389-ds but to the openSUSE Authentication Server which would then pass requests on to the 389-ds server.
On second thought I think I’m gonna give up on samba integration, at least for now.
All I wanted to do is have centrally managed user accounts, for now I don’t care for other stuff that I can achieve with samba (I don’t even have Pro versions of Windows in my company, just Homes so I can’t connect to domain).
I will just force my generated passwords on samba accounts which users wouldn’t know.
I’m hoping that SUSE/openSUSE team will update LDAP server documentation, because they switched to 389-ds in Leap 15.0 and just ignored the fact that there is no documentation. The Red Hat and Fedora ones doesn’t seem to fully match with openSUSE.