Rocky join AD but from gui user is unknow

[frankz66]

Hello everyone, I use rocky linux on AD, that is I joined on an AD server and it works almost everything. From ssh I can access with any AD server username, I modified lightdm to login with any AD user and everything works . the problem from gui is that when I log in, he gets me in, so I am an AD user on PC linux. When I perform caja, nautilus or otherwise, the problem is that although I have logged in as a user , for network connections the server does not recognize me as a valid user , in short, the connection as a guest is attempted and not as the real domain user .
It’s a problem I’ve had for a long time but I haven’t been able to solve. It only works on an old ubuntu where by browsing the net with caja or nautilius, I can get inside the folders and if I write a file I have a folder, this assumes the permissions of the owner.

[hortimech]

As you mention caja etc, I take it you are also connecting to SMB shares, if so, are you using sssd, winbind, or both.

[frankz66]

Hello , I certainly turn the network or I type the path that intesses me . As previously written it seems that when I soon create folders are not written with the permissions of the user with whom I logged in to gdm or lighdm. If I open a shell in the graphic session, and I type the pwd my path is corrected by the home on a group for example internal/user. My id corresponds, and if I perform the command “id jhon” with the command I return the gid and the correct uid ". If I move in caja or pacmfile, nautilus or whatever, I expect queries on the AD server to take place or rather be derived from the current user, but this does not happen.

[hortimech]

Please answer the question I asked you, are you using sssd, winbind or both ?
If you are running winbind, can you please post the output of ‘testparm -s’

[frankz66]

He apologizes, the translation deceived me. I not use Winbind but SSSD

[sssd]
domains = ad.internal2.lan
config_file_version = 2
services = nss, pam, ssh
default_domain_suffix = ad.internal2.lan
[nss]
homedir_substring = /home
[domain/ad.internal2.lan]
ad_gpo_access_control = permissive
krb5_store_password_if_offline = True
cache_credentials = True
krb5_realm = AD.INTERNAL2.LAN
realmd_tags = manages-system joined-with-adcli 
id_provider = ad
override_homedir = /home/%u   
fallback_homedir = /home/%u@%d
override_shell = /bin/bash
ad_domain = ad.internal2.lan
use_fully_qualified_names = True
ldap_id_mapping = True
access_provider = ad
default_shell = /bin/bash
dyndns_update = true
dyndns_refresh_interval = 43200
dyndns_update_ptr = true
dyndns_ttl = 3600
simple_allow_users = francesco

[hortimech]

I should have realised, English is not your first language, no problem, I will attempt to explain in simple language.

sssd and anything to do with shares is bad.

You need the Samba smbd daemon for shares and this requires winbind.

There is no point in running sssd and winbind, they both do the same thing.

I can assure you that Rocky Linux 9 and Samba (without sssd) works.

[frankz66]

Thank you for your understanding, you sometimes do from the translation the meaning can be mailyt.

[frankz66]

For example, even on a debian it behaves the same way, but in the debian I have winbins and smbd. I attach the testparm -s, maybe you can immediately see if something is wrong.

# Global parameters
[global]
	dns proxy = No
	domain master = No
	idmap gid = 10000-20000
	idmap uid = 10000-20000
	local master = No
	log file = /var/log/samba/%m.log
	max log size = 50
	preferred master = No
	realm = AD.INTERNAL.LAN
	security = ADS
	socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
	template shell = /bin/bash
	winbind enum groups = Yes
	winbind enum users = Yes
	winbind use default domain = Yes
	workgroup = INTERNAL
	idmap config * : range = 10000-20000
	idmap config * : backend = tdb
	create mask = 02770
	directory mask = 02777
	force create mode = 02770

[hortimech]

I see lots of problems, it looks like it grew out of a very old setup.

try this one:

[global]
	workgroup = INTERNAL
	security = ADS
	realm = AD.INTERNAL.LAN

	winbind use default domain = Yes
        winbind refresh tickets = Yes
	dns proxy = No

	idmap config * : backend = tdb
	idmap config * : range = 3000-7999
	idmap config INTERNAL : backend = rid
        idmap config INTERNAL : range = 10000-999999
	template shell = /bin/bash

        vfs objects = acl_xattr
        map acl inherit = Yes

	log file = /var/log/samba/%m.log
	max log size = 50

Check that /etc/krb5.conf looks like this:

[libdefaults]
    default_realm = AD.INTERNAL.LAN
    dns_lookup_realm = false
    dns_lookup_kdc = true

[realms]
    AD.INTERNAL.LAN = {
    default_domain = ad.internal.lan
    }

[domain_realm]
    YOUR_COMPUTERS_SHORT_HOSTNAME_IN_UPPERCASE = AD.INTERNAL.LAN

Replace ‘YOUR_COMPUTERS_SHORT_HOSTNAME_IN_UPPERCASE’ with your computers short hostname in uppercase.

Use realm to leave the domain.
Stop any Samba processes.
If using a fixed ipaddress, ensure that /etc/hosts contains a like this:

the_computers_ipaddress the_computers_FQDN the_computers_short_hostname

Now rejoin the domain with:

net ads join -U Administrator

You can replace Administrator with any username that has the right to join machines to the domain.
Once joined, restart Samba
Stop and mask sssd.

You should now be good to go.

[frankz66]

Hi I Modify what you wrote, however if I modify the samba file qunado I enter the username and password the GMD session starts again, that is, it seems that the user can enter, but returns to the main session.
On the other hand I now see all the groups but as per image as soon as I try to browse inside the wkg internal the error appears. If I type the correct share path hooks the folder.

[hortimech]

For the logon problem, do you have all these packages installed:

oddjob oddjob-mkhomedir samba-winbind samba-winbind-clients samba-common-tools bind-utils samba

Have you run these commands:

authselect select winbind with-mkhomedir --force
systemctl enable --now oddjobd.service
systemctl start oddjobd.service

As for the GUI, I suggest you take that up with Gnome, it is known problem and sadly, as far as I am aware, they haven’t yet fixed it.
Try using ‘Connect to server’

[frankz66]

Yes, I have always included the tool to create the folder automatically in the installation for the join.

[hortimech]

I am a bit lost here now, provided everything is set up correctly, it should just work from the OS and Samba point of view. I can usually get Samba working on most distros, provided you use the same setup methods, the only problem usually being anything that uses the gvfs libs, they are broken at present (have been for quite sometime) and will not allow you to connect through the gui apps.

[frankz66]

In fact , in the installations that I have been running guà for a few years , as written in predience the ubuntu versions with LXD and some modifications to lxd.conf were able to write folders and files with the correct permissions . In the past I had noticed that it was necessary to install the gvfs support, moreover as you pointed out that such support is essential for GuI. Finally, I can say, that gmd3 compared to lxde, if the user is not created and therefore as you know from shell via mkdirobject creates the hoem, I noticed with pleasant surprise that GMD3 does it automatically, and you see it in the login phase. At the moment I thank you for the interest and time you have dedicated to me and this problem. Everything else works great.

[hortimech]

I am not 100% sure just what you are saying there, but just in case you misunderstand, you should not create local Unix users & groups, just create them in AD and Samba will make them Unix users & groups as well.

[frankz66]

You misunderstood, it’s the translation’s fault!!! What I wanted to say is that I manage the users from the windows server, create them, change passwords, groups, GPOs etc. When on Linux via GMD I log in with a new user created by the Windows server, login is allowed and as written before I see the creation of his home in the graphical login…

[hortimech]

I wasn’t 100% sure what you meant and we English have a saying ‘Better safe than sorry’, so I thought I would mention it.

[frankz66]

HAI done well indeed very well! Better to remove all doubt! Cmq from what I understood and suspected the problem is gvfs.