LDAP client

I am trying to install a new computer which is a client in my network.
As such it should have LDAP clinet to authenticate against the users defined on the LDAP Server.
Unfortunately openSuSE has change the whole thing in 13.2.
There is no longer a LDAP client and LDAP browser. Now there is a Authentification Client which Looks rather murky to me.

I do not find how to set up the SSL/TLS config of the client.
Without that I cannot get any further because I cannot connect to the LDAP Server.

Can anybody tell me where I find documentation how to set up an LDAP client ?
I had the whole story running fine with 13.1 …

Suworow wrote on 11/11/2014 10:26 AM:
> I do not find how to set up the SSL/TLS config of the client.
> Without that I cannot get any further because I cannot connect to the
> LDAP Server.

I can’t try it right now, but did you try using port 636 in the LDAP URI?

Uwe

I have to say it is not only your profile pic which is tempting me to reply: “SILENCE - I’LL KILL YOU.” - it is your answer as well.
Sorry, I do not want to appear rude here, so please take this as a joke. Keif halak, Ahmed? Ham dul’Allah you are not in the box with Walter.

But several things I would like to mention here:

  1. The secure transport layer should not be initiated by choosing a particuliar port. This is a deprecated method. It should be initiated by a START_TLS command. Would you agree? And I find no hint how to do this with 13.2.
  2. I had the entire story running with openSuSE 13.1. Was not a big story there to set up the LDAP client with SSL or TLS. Now in 13.2 everything looks much different. I trust it is not so different, but there is NO DOCUMENTATION available.
  3. Does SuSE want everybody run away to Ubuntu, Fedora or Госпожа великая Дебияна who is not willing to pay for SLES but wanting to set up a decent system anyhow ?

I’m having the same problem. I configured sssd, which I actually don’t want to use - this is a desktop machine, it will never not be able to communicate with the LDAP server.

This was a new install, though the machine was already running 12.3 it couldn’t upgrade as the /boot filesystem was too small. Cue re-partitioning the entire HD.

The old yast plugin for configuring the LDAP client was simple and intuitive. That is no longer the case.

Having messed around in yast2-authentication-client, I know this machine can communicate with the LDAP server as (user id pseudo-randomized to protect the semi-innocent) “id john” returns “uid=1001(john) gid=100(users) groups=100(users)”, however, the list of groups is far from complete and attempting to login as john fails. A “su john” as a local non-privileged user returns “su: Authentication service cannot retrieve authentication info”.

Until this is resolved, this client machine is a rather expensive brick.

/jona.

Same problem here.

I’ve upgraded one of my PCs to 13.2 and I now find everything is very different. I had presumed ‘Authentication Client’ is where LDAP is now configured but there isn’t much I can find on the web that provides a guide on how to configure an LDAP Client.

jona2402 implies this needs to be ‘resolved’, but is this a possible bug that needs fixing, or is it just a case of having the knowledge to set up LDAP using the new method in YaST?

Hi, Jona!

This is exactly the status which I have reached as well.
Mounting the /home directory via NFS Shows me that the client “knows” the users by their userids but it does not “know” the group ids.
“su” to an LDAP user Fails ion same way as on your machine.

The wireshark Shows me that the client is not attempting to contact the LDAP Server via TLS but is trying on plain text LDAP Connection.

I would appreciate any help about Setting up the LDAP client.
If this will not be resolved until the Weekend I will have to set up the Client with Ubuntu or Debian where the LDAP client can be set up with a handful of entries in ldap.conf.

It is rather annoying that SuSE is changing things without documenting them.

Hi,

I too have upgraded from 13.1 to 13.2, and the workstation can no longer allows to the LDAP server.

I found that the ‘Common Server Certificate’ was no longer shown in Yast; so I’ve reloaded it.
I found I needed to load the yast-authentication-client.
I also needed to re-open the sshd port in the firewall and enable/start the sshd.

using a shell I logged into the localhost (with an existing user) ssh <existingUser>@<host>
TLS fails;
I looked at messages (tail -f /var/log/messages); and note
sssd[be[default]]: Could not start TLS encryption. #020

In the yast-authentication-client; I select the domain/default for edit; use ‘new’ to add ldap_tls_reqcert;
this allows you to select the rigour of the application of tls; if you have an internal network with ‘self certification’ this allows you to overcome tls objections;

Users can now login

Hope this helps

Could somebody translate the previous post to English please?

The problem is that I do not understand the post in its original language whatever that language my be…

If it helps:

When you set up a standard LDAP client you implement a certificate for the user store back end, configure dependent transport protocols and configure the systems to load and use the appropriate modules and libraries.

In the context of standard PAM_LDAP:

  1. Implement access to the correct certs (local usually) and how they are used (TLS_REQCERT = HARD, DEMAND, NEVER etc). by the daemon to enforce the validation of the certificate (hostname matched domain, CA signing chain, etc).

2 Decide if the transport protocol will be SSL (URI will be LDAPS://), TLS (URI can be LDAP://) of both depending on the client (can the all client send a “START_TLS” command? Best to use LDAPS:// then). The back end will usually dictate the levels of SSL and TLS support so ask your back end admin if you are unsure.

  1. Configure PAM to load and reference the required modules (in /etc/pam.d )and configure any client or daemon configuration files (/etc/ldap.conf. /etc/nslcd.conf, etc).

All of this can be done manually, but YaST does it for you well enough obviously.

The same is true for the SSSD if you apply the same concepts.

Again, I’ll reference the basic manual approach so what YaST is asking you seems a little more clear.

  1. You will still need your certificate(s) for your user store back end.

  2. use the same transport protocol your previous LDAP configuration did, initially (Consider a update to TLS from SSL if possible later ?)

  3. Implement the PAM configuration and the required configuration files.

If the system uses existing authentication methods, ass them and de-configure them first.

install the sssd and sssd-ldap packages

Configure PAM:
pam-config --query --ldap
pam-config --query --krb5

pam-config --delete --ldap --krb5

pam-config --add --sss

To create home dirs on login:

pam-config --add --sss --mkhomedir

Add/modify to the /etc/nsswitch.conf:

passwd files sss
group files sss

Create the /etc/sssd/sssd.conf (owner must be root:root, permissions must be 600) (This example uses an AD back end):

[sssd]
config_file_version = 2
services = nss,pam
domains = dvc.darkvixen.com

[nss]
reconnection_retries = 3
filter_users = root
filter_groups = root

[pam]
reconnection_retries = 3

[domain/dvc.darkvixen.com]
id_provider = ldap
auth_provider = ldap

enumerate = False
cache_credentials = True

ldap_uri = ldap://dvc.darkvixen.com

ldap_search_base = dc=dvc,dc=darkvixen,dc=com
ldap_user_search_base = ou=users,dc=dvc,dc=darkvixen,dc=com
ldap_group_search_base = ou=groups,dc=dvc,dc=darkvixen,dc=com

ldap_schema = ad
ldap_id_mapping = False
ldap_referrals = False
ldap_tls_cacert = /etc/openldap/cacerts/uga-CAs.pem
ldap_tls_reqcert = never

ldap_default_bind_dn = CN=ldap-proxy,ou=proxies,dc=dvc,dc=darkvixen,dc=com
ldap_default_authtok_type = password
ldap_default_authtok = secret

Most of this info should be present in your current LDAP configuration.

Again, of course YaST can manage all of this for you if the concepts are understood.

– lawrence

It is nice that you try to help. But are you aware of the fact that this thread is about 1½ year old? The original posters will long ago have stopped being subscribed to it. The software versions will have changed. In short, how useful is this still?

:slight_smile: , my rationale:

Helpful I think yes as many are still trying to understand the SSSD. The thread initiator is very, very likely no longer in need of the information, however someone else who finds it in a search may be helped by it.

– lawrence

But putting your information here (and you did the same in even older threads) will probably not reach many people. Those old threads are more or less black holes.

You will reach more people by starting a new thread. And when you can describe a general soolution for a certain area of knowledge, to me the Unreviewed Howto looks like a good place.

It helped me.
I googled for my LDAP problem and got to this page.

Thanks

… tis alright :slight_smile: , glad it helped!

– lawrence