user logon - blank workgroup

Hi.

I am testing Active Directory integration with Leap 15.2.

I have followed this guide:

https://doc.opensuse.org/documentation/leap/security/html/book-security/cha-security-ad.html#fig-security-logonmanagement-enroll

and in particular the section:

7.3.2 Joining Active Directory Using *User Logon Management
*
When I try to add a new domain a pop-up windows with “Active Directory enrollment” comes out.

All fields are correctly popolated but workgroup field is blank and if I try to go on and insert username and password of ad domain admin I obtain the following error:

failed to join domain: invalid configuration (“workgroup” set to ‘’, should be MADDANT). “MADDANT” is my correct realm.

But the question is: where can I specify the workgroup settings in user logon management? I did not found it.

Regards

@antonio.tvr:

What happens if, you attempt to join an Active Directory Domain? – <https://doc.opensuse.org/documentation/leap/security/html/book-security/cha-security-ad.html#sec-security-ad-winbind>

Hi.

What you have indicated is the other method described in the documentation.

But reading the docs it is explained that the preferred one is user logon management for active directory.

In the other way (winbind) it works, but I don’t understand why I cannot use user logon management if I made the same configurations indicated in docs.

Regards

MS Windows uses either Active Directory (Domain) or (exclusive or), a Workgroup …

  • In the Windows world. AD Domains and Workgroups on the same Network Segment can have identical names – I’m not sure if a Linux Samba Client can also handle this.

Do you have the “realmd” package installed?

Does “realm join {domain}” do anything?

Does the /etc/samba/smb.conf file contain something like this:


[global]

workgroup = *SHORT_NAME_OF_AD_DOMAIN*
client signing = yes
client use spnego = yes
kerberos method = secrets and keytab
realm = *AD.DOMAIN.FULL.NAME*
security = ads

Do you have Kerberos installed?

Hi.

I dont understand.

Opensuse docs says that all missing packages Will be installed by yast.

And seems that happens.

I dont understand why the user logon join procedure requires workgroup and dont ask to configure that parameter.

Reading the documentation i think that the process is Easy and for example with winbind procedure It is so.

Regards

A personal SOP Iv’e developed no matter the operating system(even MSWindows) joining a machine to a Domain is to create an /etc/hosts entry pointing to the FQDN (yes, both machine and domain) to the Domain Controller. I don’t rely on DHCP/DNS/DC all set up working correctly in harmony on the network… which is what should happen but doesn’t always. By doing this, your machine won’t depend on DNS and DHCP working perfectly and your machine knows exactly how to contact the DC that grants permission to join.

May work for you.

TSU

“Normal” Software {not Artificial Intelligence} never operates on assumptions …

  • Did you really check that the Realmd and Kerberos packages have been installed and, all the dependent packages needed by those two packages?
  • Does /etc/samba/smb.conf
    contain the required “workgroup = ” and “realm = ” entries? - From a user “root” CLI, did “realm join {domain}
    ” behave as expected?

If the manual method succeeds then, yes Bug Reports against the openSUSE Security Handbook and YaST will be needed …

  • Possibly with the suggestion made by tsu2 …

I didn’t say yast has to do magic.

but if a procedure is indicated in the documentation I usually follow it to the letter to avoid doing things not foreseen instead of those indicated.

having said that, if the domain join with winbind works I would say that there are no problems in contacting the domain controller, indeed.

I will try to put the configurations that you have indicated in samba and then try to do the join procedure.

If it will not work I sure report the bug and in the meantime I will use winbind (I don’t know for a “normal” use of a linux client joined to windows domain what are differences with winbind).

Thank you for your help

Hi.

Some updates.

User logon procedure in yast did already write all configurations indicated in smb.conf.

I have only added WORKGROUP configuration and now it is not blank.

From a root shell I have tried to join my domain with realm join -v domain

and I obtain these errors (the computer entry it is created in Active Directory, I can see it in Users and Computers):

  • /usr/bin/systemctl enable sssd.service
    Created symlink /etc/systemd/system/multi-user.target.wants/sssd.service → /usr/lib/systemd/system/sssd.service.
  • /usr/bin/systemctl restart sssd.service
    Job for sssd.service failed because the control process exited with error code.
    See “systemctl status sssd.service” and “journalctl -xe” for details.
  • /usr/sbin/pam-config --add --sssd --mkhomedir
    pam-config: invalid option – --sssd
    Try pam-config --help' or pam-config --usage’ for more information.
    ! Enabling SSSD in nsswitch.conf and PAM failed.
    realm: Couldn’t join realm: Enabling SSSD in nsswitch.conf and PAM failed.

But the first part of log is without errors and I have found the computer in AD.

This is the error log of sssd.service:

Sep 16 15:35:41 lnx02.maddant.local systemd[1]: Starting System Security Services Daemon…
Sep 16 15:35:41 lnx02.maddant.local sssd[17294]: NSCD socket was detected and seems to be configured to cache some of the databases controlled by SSSD [passwd,group,netgroup,services]. It is recommended not to run NSCD in paralle>
Sep 16 15:35:41 lnx02.maddant.local sssd[17294]: Starting up
Sep 16 15:35:41 lnx02.maddant.local sssd[be[17295]: Starting up
Sep 16 15:35:41 lnx02.maddant.local sssd[be[17296]: Starting up
Sep 16 15:35:43 lnx02.maddant.local sssd[be[17297]: Starting up
Sep 16 15:35:46 lnx02.maddant.local sssd[17298]: Starting up
Sep 16 15:35:46 lnx02.maddant.local sssd[17299]: Starting up
Sep 16 15:35:46 lnx02.maddant.local sssd[17300]: Starting up
Sep 16 15:35:46 lnx02.maddant.local sssd[17301]: Starting up
Sep 16 15:35:47 lnx02.maddant.local sssd[be[17302]: Starting up
Sep 16 15:35:47 lnx02.maddant.local sssd[17294]: Exiting the SSSD. Could not restart critical service [maddant.local].
Sep 16 15:35:47 lnx02.maddant.local systemd[1]: sssd.service: Main process exited, code=exited, status=1/FAILURE
Sep 16 15:35:47 lnx02.maddant.local systemd[1]: Failed to start System Security Services Daemon.
Sep 16 15:35:47 lnx02.maddant.local systemd[1]: sssd.service: Unit entered failed state.
Sep 16 15:35:47 lnx02.maddant.local systemd[1]: sssd.service: Failed with result ‘exit-code’.

I don’t know how can I solve this issue.

Regards

I have stopped and disabled nscd service but I obtain anyway the error of ncsd socket detected.

Thank you

Although you can search your system logs,
You might find it easier to open a console that displays your system log entries in real time before you try to join AD.
I’m guessing that might display the reason why the sssd service won’t start.
At the very least, you’ll be able to verify the service name is sssd.service or something like that.

In an elevated console, run the following command to display your system log in real time

journalctl -f

Any time you invoke the status of a service, it will display and include a relevant snippet of the system log whether it’s running or not

systemctl status* Unit_filename *

Although you shouldn’t have to do it, you can even try starting the service manually. So, for instance if the service name is sssd.service

systemctl start sssd.service

TSU

From the CLI of the user “root”, please post the output of “systemctl status sssd.service”.

For the case of the systemd Journal – also from the CLI of the user “root” – please post the output of “journalctl -x| grep -iE ‘sssd|System Security Services’ ”

Hi.

This is the output of systemctl status sssd:

sssd.service - System Security Services Daemon
Loaded: loaded (/usr/lib/systemd/system/sssd.service; disabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Wed 2020-09-16 16:22:52 CEST; 16h ago
Process: 1571 ExecStart=/usr/sbin/sssd -i ${DEBUG_LOGGER} (code=exited, status=4)
Main PID: 1571 (code=exited, status=4)

Sep 16 16:22:51 lnx02.maddant.local systemd[1]: Starting System Security Services Daemon…
Sep 16 16:22:51 lnx02.maddant.local sssd[1571]: SSSD couldn’t load the configuration database [2]: No such file or directory.
Sep 16 16:22:52 lnx02.maddant.local systemd[1]: sssd.service: Main process exited, code=exited, status=4/NOPERMISSION
Sep 16 16:22:52 lnx02.maddant.local systemd[1]: Failed to start System Security Services Daemon.
Sep 16 16:22:52 lnx02.maddant.local systemd[1]: sssd.service: Unit entered failed state.
Sep 16 16:22:52 lnx02.maddant.local systemd[1]: **sssd.service: Failed with result ‘exit-code’.

[FONT=arial]It is indicated that the configuration database could not be loaded ( I think that it should be loaded from **[/FONT][FONT=arial]/var/lib/sss/db/.

But in this directory there is the config.ldb file. I have also tried to delete it and when I start sssd service the file is created.
[/FONT]

And this is the other required information:

journalctl -x| grep -iE ‘sssd|System Security Services’
Sep 16 16:14:21 lnx02.maddant.local systemd[1]: Starting System Security Services Daemon…
– Subject: Unit sssd.service has begun start-up
– Unit sssd.service has begun starting up.
Sep 16 16:14:21 lnx02.maddant.local sssd[1411]: SSSD couldn’t load the configuration database [2]: No such file or directory.
Sep 16 16:14:21 lnx02.maddant.local systemd[1]: sssd.service: Main process exited, code=exited, status=4/NOPERMISSION
Sep 16 16:14:21 lnx02.maddant.local systemd[1]: Failed to start System Security Services Daemon.
– Subject: Unit sssd.service has failed
– Unit sssd.service has failed.
Sep 16 16:14:21 lnx02.maddant.local systemd[1]: sssd.service: Unit entered failed state.
Sep 16 16:14:21 lnx02.maddant.local systemd[1]: sssd.service: Failed with result ‘exit-code’.
Sep 16 16:14:57 lnx02.maddant.local systemd[1]: Starting System Security Services Daemon…
– Subject: Unit sssd.service has begun start-up
– Unit sssd.service has begun starting up.
Sep 16 16:14:57 lnx02.maddant.local sssd[1425]: SSSD couldn’t load the configuration database [2]: No such file or directory.
Sep 16 16:14:57 lnx02.maddant.local systemd[1]: sssd.service: Main process exited, code=exited, status=4/NOPERMISSION
Sep 16 16:14:57 lnx02.maddant.local systemd[1]: Failed to start System Security Services Daemon.
– Subject: Unit sssd.service has failed
– Unit sssd.service has failed.
Sep 16 16:14:57 lnx02.maddant.local systemd[1]: sssd.service: Unit entered failed state.
Sep 16 16:14:57 lnx02.maddant.local systemd[1]: sssd.service: Failed with result ‘exit-code’.
Sep 16 16:20:03 lnx02.maddant.local systemd[1]: Starting System Security Services Daemon…
– Subject: Unit sssd.service has begun start-up
– Unit sssd.service has begun starting up.
Sep 16 16:20:03 lnx02.maddant.local sssd[1551]: SSSD couldn’t load the configuration database [2]: No such file or directory.
Sep 16 16:20:03 lnx02.maddant.local systemd[1]: sssd.service: Main process exited, code=exited, status=4/NOPERMISSION
Sep 16 16:20:03 lnx02.maddant.local systemd[1]: Failed to start System Security Services Daemon.
– Subject: Unit sssd.service has failed
– Unit sssd.service has failed.
Sep 16 16:20:03 lnx02.maddant.local systemd[1]: sssd.service: Unit entered failed state.
Sep 16 16:20:03 lnx02.maddant.local systemd[1]: sssd.service: Failed with result ‘exit-code’.
Sep 16 16:22:51 lnx02.maddant.local systemd[1]: Starting System Security Services Daemon…
– Subject: Unit sssd.service has begun start-up
– Unit sssd.service has begun starting up.
Sep 16 16:22:51 lnx02.maddant.local sssd[1571]: SSSD couldn’t load the configuration database [2]: No such file or directory.
Sep 16 16:22:52 lnx02.maddant.local systemd[1]: sssd.service: Main process exited, code=exited, status=4/NOPERMISSION
Sep 16 16:22:52 lnx02.maddant.local systemd[1]: Failed to start System Security Services Daemon.
– Subject: Unit sssd.service has failed
– Unit sssd.service has failed.
Sep 16 16:22:52 lnx02.maddant.local systemd[1]: sssd.service: Unit entered failed state.
Sep 16 16:22:52 lnx02.maddant.local systemd[1]: sssd.service: Failed with result ‘exit-code’.

Thank you

I can also use winbind for ad join if realmd it is not working.

I tried and it works fine I must say (the credentials on the network shares are also passed and I am not asked to authenticate again).

the only problem I encountered with winbind is this: every time I log in with the domain user, the initial desktop setup is repeated, as if the settings were not saved correctly.

For Ubuntu I have tried also another method to join the client to a Windows domain: PBIS Open (I don’t know if you know about it).

It is a project with an open source version available on github that permits join in a simple way using winbind under the hood.

with one command it can join the machine to domain and with another command configures the samba integration to also pass windows authentication to network shares.

but I think that the opensuse winbind setup present in yast can do the same things.

In ubuntu there aren’t “official” tools for doing this and so I have found this product.

Regards

@antonio.tvr:

Searching for the error message points to an old Red Hat Bug Report: <https://bugzilla.redhat.com/show_bug.cgi?id=927885>.

if there is no blank line at the end of /etc/sssd/sssd.conf, sssd wont start and you get an error in /var/log/messages about "sssd: Cannot load configuration database".

Please try the repair and, raise an openSUSE Bug Report – you’ll need to include the status and systemd Journal messages you’ve shown here.

Your error suggests that the database file isn’t accessible because of improper permissions.
Possible causes…
The database file itself has the wrong permissions.
The service accessing the database file is invoked with the wrong permissions (unlikely, but possible).
AppArmor or some other permissions management isn’t configured properly (I’m guessing this is a probably the problem).

This kind of problem if it happens is usually an installation problem, did you simply install components you thought you needed or did you install using YaST Software Manager or run the YaST AD module?

Be aware that openSUSE methods for connecting to AD changed significantly about a year ago, do not use references that are older.
Current relevant documentation:

The following is brief, but contains links to other documentation depending on your setup
Note that winbind is not normally required today, but in some instances. I’ve forgotten the exact details but it’s always required connecting to an old style NT (not AD) Domain, but can also provide support for a few AD features.

A higher level description of how things are supposed to currently work

AppArmor and Active Directory

If you need help with anything in the documentation or how to do something,
Just post…

TSU

Is a user named “sssd” installed with the Active Directory packages? – Plus, an associated group?

  • If that’s the case then, this is a not an unknown error with the files associated with a service and, their directory …

Unless someone tried to pre-create a user account (not supposed to do that),
The User should be logged be running the YaST account with elevated permissions (that’s automatic)
And
Should be using a Domain Admin account to join the Domain.

Both these requirements I’d guess shouldn’t throw the permissions error.
IMO it’s more likely local permissions erroon the machine, but how the problem happened, I don’t know…
Could be a bug.
Or, could be a User install and setup error.

TSU

Hi.

Thank you for your help.

I have tried to join an openSuse Leap 15.2 machine to AD from Yast, not from shell.

And I have followed the documentation updated for latest relase of OpenSuse.

Maybe there is some bug and it could also be true since the procedure with winbind works and the one with sssd does not.

The openSuse documentation syas that the join procedure with user logon (sssd) it best indicated for active directory.

Also on red hat portal I have found several informations regards winbind “deprecation”.

The only commercial product (but there is also an open source version) that continues to use winbind for now, at least that I know of, is pbis.

For myself and then use it on multiple workstations in the company where I work, I had preferred to do tests with yast rather than at command line attempts.

I try to open a bug with openSuse so maybe they can say wy the “offical” procedure did not works.

Regards and thank you very much for your help.