| 2021-07-08 08:20:43 |
r0mulux |
bug |
|
|
added bug |
| 2021-07-08 09:20:49 |
Jean-Baptiste Lallement |
sssd (Ubuntu): status |
New |
Triaged |
|
| 2021-07-08 09:20:54 |
Jean-Baptiste Lallement |
sssd (Ubuntu): importance |
Undecided |
High |
|
| 2021-07-08 14:02:07 |
EOLE team |
bug |
|
|
added subscriber EOLE team |
| 2021-07-15 13:38:03 |
Paride Legovini |
bug |
|
|
added subscriber Ubuntu Server |
| 2021-07-15 13:41:07 |
Paride Legovini |
tags |
|
regression-update |
|
| 2021-07-15 14:01:29 |
Sergio Durigan Junior |
bug watch added |
|
https://bugzilla.redhat.com/show_bug.cgi?id=1839805 |
|
| 2021-07-15 14:01:29 |
Sergio Durigan Junior |
bug task added |
|
sssd (Fedora) |
|
| 2021-07-15 14:25:04 |
Sergio Durigan Junior |
bug watch added |
|
https://github.com/SSSD/sssd/issues/4356 |
|
| 2021-07-16 23:08:44 |
Sergio Durigan Junior |
bug watch added |
|
https://github.com/SSSD/sssd/issues/5716 |
|
| 2021-07-16 23:08:44 |
Sergio Durigan Junior |
bug task added |
|
sssd |
|
| 2021-07-16 23:36:44 |
Bug Watch Updater |
sssd: status |
Unknown |
New |
|
| 2022-06-06 12:38:05 |
Andreas Hasenack |
tags |
regression-update |
regression-update server-todo |
|
| 2022-06-06 12:38:19 |
Andreas Hasenack |
bug |
|
|
added subscriber Canonical Server Team |
| 2022-06-06 12:40:38 |
Andreas Hasenack |
bug task added |
|
serverguide |
|
| 2022-06-06 12:40:46 |
Andreas Hasenack |
serverguide: status |
New |
Confirmed |
|
| 2022-06-06 12:40:50 |
Andreas Hasenack |
serverguide: status |
Confirmed |
Triaged |
|
| 2022-06-06 12:40:51 |
Andreas Hasenack |
serverguide: importance |
Undecided |
High |
|
| 2022-06-06 12:40:54 |
Andreas Hasenack |
serverguide: assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2022-06-06 14:51:29 |
Andreas Hasenack |
serverguide: status |
Triaged |
Fix Released |
|
| 2022-06-14 14:34:22 |
Marcos Alano |
bug |
|
|
added subscriber Marcos Alano |
| 2022-06-14 21:14:28 |
Sergio Durigan Junior |
merge proposal linked |
|
https://code.launchpad.net/~sergiodj/ubuntu/+source/sssd/+git/sssd/+merge/424698 |
|
| 2022-06-15 01:47:09 |
Sergio Durigan Junior |
nominated for series |
|
Ubuntu Impish |
|
| 2022-06-15 01:47:09 |
Sergio Durigan Junior |
bug task added |
|
sssd (Ubuntu Impish) |
|
| 2022-06-15 01:47:09 |
Sergio Durigan Junior |
nominated for series |
|
Ubuntu Jammy |
|
| 2022-06-15 01:47:09 |
Sergio Durigan Junior |
bug task added |
|
sssd (Ubuntu Jammy) |
|
| 2022-06-15 01:47:09 |
Sergio Durigan Junior |
nominated for series |
|
Ubuntu Focal |
|
| 2022-06-15 01:47:09 |
Sergio Durigan Junior |
bug task added |
|
sssd (Ubuntu Focal) |
|
| 2022-06-15 01:47:09 |
Sergio Durigan Junior |
nominated for series |
|
Ubuntu Kinetic |
|
| 2022-06-15 01:47:09 |
Sergio Durigan Junior |
bug task added |
|
sssd (Ubuntu Kinetic) |
|
| 2022-06-15 02:02:51 |
Sergio Durigan Junior |
bug |
|
|
added subscriber Sergio Durigan Junior |
| 2022-06-15 15:07:51 |
Sergio Durigan Junior |
sssd (Ubuntu Focal): assignee |
|
Sergio Durigan Junior (sergiodj) |
|
| 2022-06-15 15:07:53 |
Sergio Durigan Junior |
sssd (Ubuntu Impish): assignee |
|
Sergio Durigan Junior (sergiodj) |
|
| 2022-06-15 15:07:54 |
Sergio Durigan Junior |
sssd (Ubuntu Jammy): assignee |
|
Sergio Durigan Junior (sergiodj) |
|
| 2022-06-15 15:07:56 |
Sergio Durigan Junior |
sssd (Ubuntu Kinetic): assignee |
|
Sergio Durigan Junior (sergiodj) |
|
| 2022-06-17 00:01:36 |
Sergio Durigan Junior |
description |
Hello,
After upgrade of sssd packages from version 2.2.3-3ubuntu0.4 to version 2.2.3-3ubuntu0.6, I could not authenticate with users from my Samba4 directory.
After enabling debug, I can see in /var/log/sssd/gpo_child.log errors:
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): gpo_child started.
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): context initialized
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x0400): cached_gpt_version: -1
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_server length: 21
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_server: smb://MY_SERVER_FQDN
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_share length: 7
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_share: /sysvol
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_path length: 60
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_path: /MY_DOMAIN/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_cse_suffix length: 49
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_cse_suffix: /Machine/Microsoft/Windows NT/SecEdit/GptTmpl.inf
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): performing smb operations
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [copy_smb_file_to_gpo_cache] (0x0400): smb_uri: smb://MY_SERVER_FQDN/sysvol/MY_DOMAIN/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}/GPT.INI
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [copy_smb_file_to_gpo_cache] (0x0020): smbc_getFunctionOpen failed [13][Permission denied]
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [perform_smb_operations] (0x0020): copy_smb_file_to_gpo_cache failed [13][Permission denied]
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0020): perform_smb_operations failed.[13][Permission denied].
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0020): gpo_child failed!
(I have replaced real server and domain name by MY_SERVER_FQDN and MY_DOMAIN)
As a workaround, I add new option 'ad_gpo_access_control = permissive' in sssd.conf and authentication is working again, but I'm wondering why upgrade has broken authentication, and what is the impact of the option ?
here is my sssd.conf:
[sssd]
default_domain_suffix = my_domain
full_name_format = %1$s
domains = my_domain
config_file_version = 2
services = nss, pam
[domain/my_domain]
debug_level=9
default_shell = /bin/bash
krb5_store_password_if_offline = True
cache_credentials = True
krb5_realm = MY_DOMAIN
realmd_tags = manages-system joined-with-adcli
id_provider = ad
fallback_homedir = /home/%d/%u
ad_domain = my_domain
use_fully_qualified_names = True
ldap_id_mapping = True
access_provider = ad
After adding 'ad_gpo_access_control = permissive' at the end of file, authentication with samba4 users works again.
Thanks! |
[ Impact ]
TBD.
[ Test Plan ]
The test case for this bug is a bit complex, but I will do my best to describe it in detail.
We need to setup one VM running a Samba Active Directory Domain Controller (AD DC), which will be our main server. This needs only to be configured once. We then need to setup another VM which will join our AD DC realm using realmd and sssd.
== Virtual Network setup ==
The first step is to create a dedicated virtual network for our tests. This is not strictly mandatory, but it will simplify things. The best way to create this network is via virt-manager. Install it if needed, open the program and select the "QEMU/KVM" line. Go to Edit > Connection Details > Virtual Networks, click on the "+" icon (bottom left), give this network a name (I will use "sssdad"), make sure that "Enable IPv4" and "Enable DHCPv4" are selected (under "IPv4 configuration"). Go to "DNS domain name" and select "Custom". For the domain name, type "test.lan". Click on "Finish".
Take note of the "Device" name that shows up after you create the network. We will use it when creating the VMs. For this test plan, let's assume the device name is "virbr1".
== Samba AD DC VM setup ==
We need to setup a Samba AD DC server. It doesn't matter which Ubuntu release we use for it. Note that we have to use "-n virbr1" when creating the VM, otherwise it won't use our virtual network.
$ lxc launch ubuntu-daily:jammy sambadc -n virbr1 --vm
$ lxc shell sambadc
server# apt update
server# ip a
Make sure to grab this VM's IP address.
server# cat >> /etc/hosts << _EOF_
IP_ADDRESS_HERE sambadc sambadc.test.lan
_EOF_
server# reboot
$ lxc shell sambadc
server# apt install -y samba smbclient winbind libpam-winbind libnss-winbind krb5-kdc libpam-krb5
If you get asked to provide the Default Kerberos version 5 realm, leave the field empty and hit Enter.
server# mv /etc/samba/smb.conf /etc/samba/smb.conf.bkp
server# mv /etc/krb5.conf /etc/krb5.conf.bkp
server# samba-tool domain provision --use-rfc2307 --realm TEST.LAN --domain TEST --server-role dc --dns-backend SAMBA_INTERNAL --adminpass MyPassword1
server# cp /var/lib/samba/private/krb5.conf /etc/
Edit the file /etc/krb5.conf and, under the [libdefaults] section, add the following line:
rdns = false
Save it.
server# systemctl mask smbd.service nmbd.service winbind.service
server# systemctl disable --now smbd.service nmbd.service winbind.service
server# systemctl unmask samba-ad-dc.service
server# systemctl enable --now samba-ad-dc.service
server# systemctl disable --now systemd-resolved.service
server# unlink /etc/resolv.conf
server# cat > /etc/resolv.conf << _EOF_
nameserver 8.8.8.8
search test.lan
_EOF_
server# reboot
This should be enough to configure Samba as an AD DC. While at it, create a test user that will later be used to trigger the bug.
server# samba-tool user create testuser MyUserPassword1
== VM AD client setup ==
Let's configure a VM to act as an AD client.
$ lxc launch ubuntu-daily:jammy sssdclient -n virbr2 --vm
$ lxc shell sssdclient
client# apt update
client# apt install -y sssd-ad sssd-tools realmd adcli sssd-dbus
client# pam-auth-update --enable mkhomedir
We can now check if our container can detect the AD DC:
client# realm -v discover sambadc.test.lan
* Resolving: _ldap._tcp.sambadc.test.lan
* Resolving: sambadc.test.lan
* Performing LDAP DSE lookup on: 192.168.101.142
* Successfully discovered: test.lan
test.lan
type: kerberos
realm-name: TEST.LAN
domain-name: test.lan
configured: no
server-software: active-directory
client-software: sssd
required-package: sssd-tools
required-package: sssd
required-package: libnss-sss
required-package: libpam-sss
required-package: adcli
required-package: samba-common-bin
And we can join the realm:
client# realm -v join sambadc.test.lan
You will be prompted the password for the Administrator user. It is MyPassword1. If everything worked OK, you should now be able to list the information from the Administrator user:
client# getent passwd Administrator@TEST.LAN
administrator@test.lan:*:1522000500:1522000513:Administrator:/home/administrator@test.lan:/bin/bash
== Reproducing the bug ==
Make sure you can obtain the passwd information for the test user we've created in the Samba AD DC server.
client# getent passwd testuser@TEST.LAN
testuser@test.lan:*:1522001104:1522000513:testuser:/home/testuser@test.lan:/bin/bash
Now, try to login as the user:
client# login testuser@TEST.LAN
Password: MyUserPassword1
System error
As can be seen, the user will get a system error when trying to login in a default AD DC setup. In order to confirm that the problem is indeed caused by GPO, the following line can be added to the end of the /etc/sssd/sssd.conf file:
ad_gpo_access_control = permissive
After restarting sssd.service and trying to login again, you can confirm that it succeeds.
[ Where problems could occur ]
TBD.
[ Original Description ]
Hello,
After upgrade of sssd packages from version 2.2.3-3ubuntu0.4 to version 2.2.3-3ubuntu0.6, I could not authenticate with users from my Samba4 directory.
After enabling debug, I can see in /var/log/sssd/gpo_child.log errors:
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): gpo_child started.
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): context initialized
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x0400): cached_gpt_version: -1
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_server length: 21
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_server: smb://MY_SERVER_FQDN
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_share length: 7
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_share: /sysvol
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_path length: 60
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_path: /MY_DOMAIN/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_cse_suffix length: 49
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_cse_suffix: /Machine/Microsoft/Windows NT/SecEdit/GptTmpl.inf
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): performing smb operations
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [copy_smb_file_to_gpo_cache] (0x0400): smb_uri: smb://MY_SERVER_FQDN/sysvol/MY_DOMAIN/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}/GPT.INI
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [copy_smb_file_to_gpo_cache] (0x0020): smbc_getFunctionOpen failed [13][Permission denied]
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [perform_smb_operations] (0x0020): copy_smb_file_to_gpo_cache failed [13][Permission denied]
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0020): perform_smb_operations failed.[13][Permission denied].
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0020): gpo_child failed!
(I have replaced real server and domain name by MY_SERVER_FQDN and MY_DOMAIN)
As a workaround, I add new option 'ad_gpo_access_control = permissive' in sssd.conf and authentication is working again, but I'm wondering why upgrade has broken authentication, and what is the impact of the option ?
here is my sssd.conf:
[sssd]
default_domain_suffix = my_domain
full_name_format = %1$s
domains = my_domain
config_file_version = 2
services = nss, pam
[domain/my_domain]
debug_level=9
default_shell = /bin/bash
krb5_store_password_if_offline = True
cache_credentials = True
krb5_realm = MY_DOMAIN
realmd_tags = manages-system joined-with-adcli
id_provider = ad
fallback_homedir = /home/%d/%u
ad_domain = my_domain
use_fully_qualified_names = True
ldap_id_mapping = True
access_provider = ad
After adding 'ad_gpo_access_control = permissive' at the end of file, authentication with samba4 users works again.
Thanks! |
|
| 2022-06-17 02:04:26 |
Sergio Durigan Junior |
sssd (Ubuntu Jammy): status |
New |
In Progress |
|
| 2022-06-17 02:04:29 |
Sergio Durigan Junior |
sssd (Ubuntu Focal): status |
New |
In Progress |
|
| 2022-06-17 02:04:30 |
Sergio Durigan Junior |
sssd (Ubuntu Focal): importance |
Undecided |
High |
|
| 2022-06-17 02:04:32 |
Sergio Durigan Junior |
sssd (Ubuntu Jammy): importance |
Undecided |
High |
|
| 2022-06-17 02:10:13 |
Sergio Durigan Junior |
description |
[ Impact ]
TBD.
[ Test Plan ]
The test case for this bug is a bit complex, but I will do my best to describe it in detail.
We need to setup one VM running a Samba Active Directory Domain Controller (AD DC), which will be our main server. This needs only to be configured once. We then need to setup another VM which will join our AD DC realm using realmd and sssd.
== Virtual Network setup ==
The first step is to create a dedicated virtual network for our tests. This is not strictly mandatory, but it will simplify things. The best way to create this network is via virt-manager. Install it if needed, open the program and select the "QEMU/KVM" line. Go to Edit > Connection Details > Virtual Networks, click on the "+" icon (bottom left), give this network a name (I will use "sssdad"), make sure that "Enable IPv4" and "Enable DHCPv4" are selected (under "IPv4 configuration"). Go to "DNS domain name" and select "Custom". For the domain name, type "test.lan". Click on "Finish".
Take note of the "Device" name that shows up after you create the network. We will use it when creating the VMs. For this test plan, let's assume the device name is "virbr1".
== Samba AD DC VM setup ==
We need to setup a Samba AD DC server. It doesn't matter which Ubuntu release we use for it. Note that we have to use "-n virbr1" when creating the VM, otherwise it won't use our virtual network.
$ lxc launch ubuntu-daily:jammy sambadc -n virbr1 --vm
$ lxc shell sambadc
server# apt update
server# ip a
Make sure to grab this VM's IP address.
server# cat >> /etc/hosts << _EOF_
IP_ADDRESS_HERE sambadc sambadc.test.lan
_EOF_
server# reboot
$ lxc shell sambadc
server# apt install -y samba smbclient winbind libpam-winbind libnss-winbind krb5-kdc libpam-krb5
If you get asked to provide the Default Kerberos version 5 realm, leave the field empty and hit Enter.
server# mv /etc/samba/smb.conf /etc/samba/smb.conf.bkp
server# mv /etc/krb5.conf /etc/krb5.conf.bkp
server# samba-tool domain provision --use-rfc2307 --realm TEST.LAN --domain TEST --server-role dc --dns-backend SAMBA_INTERNAL --adminpass MyPassword1
server# cp /var/lib/samba/private/krb5.conf /etc/
Edit the file /etc/krb5.conf and, under the [libdefaults] section, add the following line:
rdns = false
Save it.
server# systemctl mask smbd.service nmbd.service winbind.service
server# systemctl disable --now smbd.service nmbd.service winbind.service
server# systemctl unmask samba-ad-dc.service
server# systemctl enable --now samba-ad-dc.service
server# systemctl disable --now systemd-resolved.service
server# unlink /etc/resolv.conf
server# cat > /etc/resolv.conf << _EOF_
nameserver 8.8.8.8
search test.lan
_EOF_
server# reboot
This should be enough to configure Samba as an AD DC. While at it, create a test user that will later be used to trigger the bug.
server# samba-tool user create testuser MyUserPassword1
== VM AD client setup ==
Let's configure a VM to act as an AD client.
$ lxc launch ubuntu-daily:jammy sssdclient -n virbr2 --vm
$ lxc shell sssdclient
client# apt update
client# apt install -y sssd-ad sssd-tools realmd adcli sssd-dbus
client# pam-auth-update --enable mkhomedir
We can now check if our container can detect the AD DC:
client# realm -v discover sambadc.test.lan
* Resolving: _ldap._tcp.sambadc.test.lan
* Resolving: sambadc.test.lan
* Performing LDAP DSE lookup on: 192.168.101.142
* Successfully discovered: test.lan
test.lan
type: kerberos
realm-name: TEST.LAN
domain-name: test.lan
configured: no
server-software: active-directory
client-software: sssd
required-package: sssd-tools
required-package: sssd
required-package: libnss-sss
required-package: libpam-sss
required-package: adcli
required-package: samba-common-bin
And we can join the realm:
client# realm -v join sambadc.test.lan
You will be prompted the password for the Administrator user. It is MyPassword1. If everything worked OK, you should now be able to list the information from the Administrator user:
client# getent passwd Administrator@TEST.LAN
administrator@test.lan:*:1522000500:1522000513:Administrator:/home/administrator@test.lan:/bin/bash
== Reproducing the bug ==
Make sure you can obtain the passwd information for the test user we've created in the Samba AD DC server.
client# getent passwd testuser@TEST.LAN
testuser@test.lan:*:1522001104:1522000513:testuser:/home/testuser@test.lan:/bin/bash
Now, try to login as the user:
client# login testuser@TEST.LAN
Password: MyUserPassword1
System error
As can be seen, the user will get a system error when trying to login in a default AD DC setup. In order to confirm that the problem is indeed caused by GPO, the following line can be added to the end of the /etc/sssd/sssd.conf file:
ad_gpo_access_control = permissive
After restarting sssd.service and trying to login again, you can confirm that it succeeds.
[ Where problems could occur ]
TBD.
[ Original Description ]
Hello,
After upgrade of sssd packages from version 2.2.3-3ubuntu0.4 to version 2.2.3-3ubuntu0.6, I could not authenticate with users from my Samba4 directory.
After enabling debug, I can see in /var/log/sssd/gpo_child.log errors:
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): gpo_child started.
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): context initialized
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x0400): cached_gpt_version: -1
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_server length: 21
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_server: smb://MY_SERVER_FQDN
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_share length: 7
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_share: /sysvol
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_path length: 60
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_path: /MY_DOMAIN/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_cse_suffix length: 49
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_cse_suffix: /Machine/Microsoft/Windows NT/SecEdit/GptTmpl.inf
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): performing smb operations
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [copy_smb_file_to_gpo_cache] (0x0400): smb_uri: smb://MY_SERVER_FQDN/sysvol/MY_DOMAIN/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}/GPT.INI
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [copy_smb_file_to_gpo_cache] (0x0020): smbc_getFunctionOpen failed [13][Permission denied]
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [perform_smb_operations] (0x0020): copy_smb_file_to_gpo_cache failed [13][Permission denied]
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0020): perform_smb_operations failed.[13][Permission denied].
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0020): gpo_child failed!
(I have replaced real server and domain name by MY_SERVER_FQDN and MY_DOMAIN)
As a workaround, I add new option 'ad_gpo_access_control = permissive' in sssd.conf and authentication is working again, but I'm wondering why upgrade has broken authentication, and what is the impact of the option ?
here is my sssd.conf:
[sssd]
default_domain_suffix = my_domain
full_name_format = %1$s
domains = my_domain
config_file_version = 2
services = nss, pam
[domain/my_domain]
debug_level=9
default_shell = /bin/bash
krb5_store_password_if_offline = True
cache_credentials = True
krb5_realm = MY_DOMAIN
realmd_tags = manages-system joined-with-adcli
id_provider = ad
fallback_homedir = /home/%d/%u
ad_domain = my_domain
use_fully_qualified_names = True
ldap_id_mapping = True
access_provider = ad
After adding 'ad_gpo_access_control = permissive' at the end of file, authentication with samba4 users works again.
Thanks! |
[ Impact ]
A user running an Active Directory Domain Controller (either from Microsoft or using Samba) compliant with the MS ADTS specifications in regards to how GPO is handled will experience authentication failures when joining an AD realm using the Ubuntu sssd package on Focal, Impish and Jammy with the "fix-gpo-MS-ADTS-compliance.patch" patch applied. Although there is a relatively simple workaround (setting "ad_gpo_access_control = permissive" in /etc/sssd/sssd.conf), we can and should support regular user authentication out of the box.
Upstream sssd has fixed this problem on version 2.7.0, which will be available in Kinetic soon.
[ Test Plan ]
The test case for this bug is a bit complex, but I will do my best to describe it in detail.
We need to setup one VM running a Samba Active Directory Domain Controller (AD DC), which will be our main server. This needs only to be configured once. We then need to setup another VM which will join our AD DC realm using realmd and sssd.
== Virtual Network setup ==
The first step is to create a dedicated virtual network for our tests. This is not strictly mandatory, but it will simplify things. The best way to create this network is via virt-manager. Install it if needed, open the program and select the "QEMU/KVM" line. Go to Edit > Connection Details > Virtual Networks, click on the "+" icon (bottom left), give this network a name (I will use "sssdad"), make sure that "Enable IPv4" and "Enable DHCPv4" are selected (under "IPv4 configuration"). Go to "DNS domain name" and select "Custom". For the domain name, type "test.lan". Click on "Finish".
Take note of the "Device" name that shows up after you create the network. We will use it when creating the VMs. For this test plan, let's assume the device name is "virbr1".
== Samba AD DC VM setup ==
We need to setup a Samba AD DC server. It doesn't matter which Ubuntu release we use for it. Note that we have to use "-n virbr1" when creating the VM, otherwise it won't use our virtual network.
$ lxc launch ubuntu-daily:jammy sambadc -n virbr1 --vm
$ lxc shell sambadc
server# apt update
server# ip a
Make sure to grab this VM's IP address.
server# cat >> /etc/hosts << _EOF_
IP_ADDRESS_HERE sambadc sambadc.test.lan
_EOF_
server# reboot
$ lxc shell sambadc
server# apt install -y samba smbclient winbind libpam-winbind libnss-winbind krb5-kdc libpam-krb5
If you get asked to provide the Default Kerberos version 5 realm, leave the field empty and hit Enter.
server# mv /etc/samba/smb.conf /etc/samba/smb.conf.bkp
server# mv /etc/krb5.conf /etc/krb5.conf.bkp
server# samba-tool domain provision --use-rfc2307 --realm TEST.LAN --domain TEST --server-role dc --dns-backend SAMBA_INTERNAL --adminpass MyPassword1
server# cp /var/lib/samba/private/krb5.conf /etc/
Edit the file /etc/krb5.conf and, under the [libdefaults] section, add the following line:
rdns = false
Save it.
server# systemctl mask smbd.service nmbd.service winbind.service
server# systemctl disable --now smbd.service nmbd.service winbind.service
server# systemctl unmask samba-ad-dc.service
server# systemctl enable --now samba-ad-dc.service
server# systemctl disable --now systemd-resolved.service
server# unlink /etc/resolv.conf
server# cat > /etc/resolv.conf << _EOF_
nameserver 8.8.8.8
search test.lan
_EOF_
server# reboot
This should be enough to configure Samba as an AD DC. While at it, create a test user that will later be used to trigger the bug.
server# samba-tool user create testuser MyUserPassword1
== VM AD client setup ==
Let's configure a VM to act as an AD client.
$ lxc launch ubuntu-daily:jammy sssdclient -n virbr2 --vm
$ lxc shell sssdclient
client# apt update
client# apt install -y sssd-ad sssd-tools realmd adcli sssd-dbus
client# pam-auth-update --enable mkhomedir
We can now check if our container can detect the AD DC:
client# realm -v discover sambadc.test.lan
* Resolving: _ldap._tcp.sambadc.test.lan
* Resolving: sambadc.test.lan
* Performing LDAP DSE lookup on: 192.168.101.142
* Successfully discovered: test.lan
test.lan
type: kerberos
realm-name: TEST.LAN
domain-name: test.lan
configured: no
server-software: active-directory
client-software: sssd
required-package: sssd-tools
required-package: sssd
required-package: libnss-sss
required-package: libpam-sss
required-package: adcli
required-package: samba-common-bin
And we can join the realm:
client# realm -v join sambadc.test.lan
You will be prompted the password for the Administrator user. It is MyPassword1. If everything worked OK, you should now be able to list the information from the Administrator user:
client# getent passwd Administrator@TEST.LAN
administrator@test.lan:*:1522000500:1522000513:Administrator:/home/administrator@test.lan:/bin/bash
== Reproducing the bug ==
Make sure you can obtain the passwd information for the test user we've created in the Samba AD DC server.
client# getent passwd testuser@TEST.LAN
testuser@test.lan:*:1522001104:1522000513:testuser:/home/testuser@test.lan:/bin/bash
Now, try to login as the user:
client# login testuser@TEST.LAN
Password: MyUserPassword1
System error
As can be seen, the user will get a system error when trying to login in a default AD DC setup. In order to confirm that the problem is indeed caused by GPO, the following line can be added to the end of the /etc/sssd/sssd.conf file:
ad_gpo_access_control = permissive
After restarting sssd.service and trying to login again, you can confirm that it succeeds.
[ Where problems could occur ]
TBD.
[ Original Description ]
Hello,
After upgrade of sssd packages from version 2.2.3-3ubuntu0.4 to version 2.2.3-3ubuntu0.6, I could not authenticate with users from my Samba4 directory.
After enabling debug, I can see in /var/log/sssd/gpo_child.log errors:
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): gpo_child started.
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): context initialized
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x0400): cached_gpt_version: -1
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_server length: 21
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_server: smb://MY_SERVER_FQDN
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_share length: 7
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_share: /sysvol
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_path length: 60
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_path: /MY_DOMAIN/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_cse_suffix length: 49
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_cse_suffix: /Machine/Microsoft/Windows NT/SecEdit/GptTmpl.inf
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): performing smb operations
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [copy_smb_file_to_gpo_cache] (0x0400): smb_uri: smb://MY_SERVER_FQDN/sysvol/MY_DOMAIN/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}/GPT.INI
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [copy_smb_file_to_gpo_cache] (0x0020): smbc_getFunctionOpen failed [13][Permission denied]
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [perform_smb_operations] (0x0020): copy_smb_file_to_gpo_cache failed [13][Permission denied]
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0020): perform_smb_operations failed.[13][Permission denied].
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0020): gpo_child failed!
(I have replaced real server and domain name by MY_SERVER_FQDN and MY_DOMAIN)
As a workaround, I add new option 'ad_gpo_access_control = permissive' in sssd.conf and authentication is working again, but I'm wondering why upgrade has broken authentication, and what is the impact of the option ?
here is my sssd.conf:
[sssd]
default_domain_suffix = my_domain
full_name_format = %1$s
domains = my_domain
config_file_version = 2
services = nss, pam
[domain/my_domain]
debug_level=9
default_shell = /bin/bash
krb5_store_password_if_offline = True
cache_credentials = True
krb5_realm = MY_DOMAIN
realmd_tags = manages-system joined-with-adcli
id_provider = ad
fallback_homedir = /home/%d/%u
ad_domain = my_domain
use_fully_qualified_names = True
ldap_id_mapping = True
access_provider = ad
After adding 'ad_gpo_access_control = permissive' at the end of file, authentication with samba4 users works again.
Thanks! |
|
| 2022-06-17 07:42:40 |
Jakub Hrozek |
bug |
|
|
added subscriber Jakub Hrozek |
| 2022-06-17 07:42:47 |
Jakub Hrozek |
removed subscriber Jakub Hrozek |
|
|
|
| 2022-06-17 15:08:19 |
Sergio Durigan Junior |
description |
[ Impact ]
A user running an Active Directory Domain Controller (either from Microsoft or using Samba) compliant with the MS ADTS specifications in regards to how GPO is handled will experience authentication failures when joining an AD realm using the Ubuntu sssd package on Focal, Impish and Jammy with the "fix-gpo-MS-ADTS-compliance.patch" patch applied. Although there is a relatively simple workaround (setting "ad_gpo_access_control = permissive" in /etc/sssd/sssd.conf), we can and should support regular user authentication out of the box.
Upstream sssd has fixed this problem on version 2.7.0, which will be available in Kinetic soon.
[ Test Plan ]
The test case for this bug is a bit complex, but I will do my best to describe it in detail.
We need to setup one VM running a Samba Active Directory Domain Controller (AD DC), which will be our main server. This needs only to be configured once. We then need to setup another VM which will join our AD DC realm using realmd and sssd.
== Virtual Network setup ==
The first step is to create a dedicated virtual network for our tests. This is not strictly mandatory, but it will simplify things. The best way to create this network is via virt-manager. Install it if needed, open the program and select the "QEMU/KVM" line. Go to Edit > Connection Details > Virtual Networks, click on the "+" icon (bottom left), give this network a name (I will use "sssdad"), make sure that "Enable IPv4" and "Enable DHCPv4" are selected (under "IPv4 configuration"). Go to "DNS domain name" and select "Custom". For the domain name, type "test.lan". Click on "Finish".
Take note of the "Device" name that shows up after you create the network. We will use it when creating the VMs. For this test plan, let's assume the device name is "virbr1".
== Samba AD DC VM setup ==
We need to setup a Samba AD DC server. It doesn't matter which Ubuntu release we use for it. Note that we have to use "-n virbr1" when creating the VM, otherwise it won't use our virtual network.
$ lxc launch ubuntu-daily:jammy sambadc -n virbr1 --vm
$ lxc shell sambadc
server# apt update
server# ip a
Make sure to grab this VM's IP address.
server# cat >> /etc/hosts << _EOF_
IP_ADDRESS_HERE sambadc sambadc.test.lan
_EOF_
server# reboot
$ lxc shell sambadc
server# apt install -y samba smbclient winbind libpam-winbind libnss-winbind krb5-kdc libpam-krb5
If you get asked to provide the Default Kerberos version 5 realm, leave the field empty and hit Enter.
server# mv /etc/samba/smb.conf /etc/samba/smb.conf.bkp
server# mv /etc/krb5.conf /etc/krb5.conf.bkp
server# samba-tool domain provision --use-rfc2307 --realm TEST.LAN --domain TEST --server-role dc --dns-backend SAMBA_INTERNAL --adminpass MyPassword1
server# cp /var/lib/samba/private/krb5.conf /etc/
Edit the file /etc/krb5.conf and, under the [libdefaults] section, add the following line:
rdns = false
Save it.
server# systemctl mask smbd.service nmbd.service winbind.service
server# systemctl disable --now smbd.service nmbd.service winbind.service
server# systemctl unmask samba-ad-dc.service
server# systemctl enable --now samba-ad-dc.service
server# systemctl disable --now systemd-resolved.service
server# unlink /etc/resolv.conf
server# cat > /etc/resolv.conf << _EOF_
nameserver 8.8.8.8
search test.lan
_EOF_
server# reboot
This should be enough to configure Samba as an AD DC. While at it, create a test user that will later be used to trigger the bug.
server# samba-tool user create testuser MyUserPassword1
== VM AD client setup ==
Let's configure a VM to act as an AD client.
$ lxc launch ubuntu-daily:jammy sssdclient -n virbr2 --vm
$ lxc shell sssdclient
client# apt update
client# apt install -y sssd-ad sssd-tools realmd adcli sssd-dbus
client# pam-auth-update --enable mkhomedir
We can now check if our container can detect the AD DC:
client# realm -v discover sambadc.test.lan
* Resolving: _ldap._tcp.sambadc.test.lan
* Resolving: sambadc.test.lan
* Performing LDAP DSE lookup on: 192.168.101.142
* Successfully discovered: test.lan
test.lan
type: kerberos
realm-name: TEST.LAN
domain-name: test.lan
configured: no
server-software: active-directory
client-software: sssd
required-package: sssd-tools
required-package: sssd
required-package: libnss-sss
required-package: libpam-sss
required-package: adcli
required-package: samba-common-bin
And we can join the realm:
client# realm -v join sambadc.test.lan
You will be prompted the password for the Administrator user. It is MyPassword1. If everything worked OK, you should now be able to list the information from the Administrator user:
client# getent passwd Administrator@TEST.LAN
administrator@test.lan:*:1522000500:1522000513:Administrator:/home/administrator@test.lan:/bin/bash
== Reproducing the bug ==
Make sure you can obtain the passwd information for the test user we've created in the Samba AD DC server.
client# getent passwd testuser@TEST.LAN
testuser@test.lan:*:1522001104:1522000513:testuser:/home/testuser@test.lan:/bin/bash
Now, try to login as the user:
client# login testuser@TEST.LAN
Password: MyUserPassword1
System error
As can be seen, the user will get a system error when trying to login in a default AD DC setup. In order to confirm that the problem is indeed caused by GPO, the following line can be added to the end of the /etc/sssd/sssd.conf file:
ad_gpo_access_control = permissive
After restarting sssd.service and trying to login again, you can confirm that it succeeds.
[ Where problems could occur ]
TBD.
[ Original Description ]
Hello,
After upgrade of sssd packages from version 2.2.3-3ubuntu0.4 to version 2.2.3-3ubuntu0.6, I could not authenticate with users from my Samba4 directory.
After enabling debug, I can see in /var/log/sssd/gpo_child.log errors:
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): gpo_child started.
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): context initialized
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x0400): cached_gpt_version: -1
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_server length: 21
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_server: smb://MY_SERVER_FQDN
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_share length: 7
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_share: /sysvol
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_path length: 60
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_path: /MY_DOMAIN/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_cse_suffix length: 49
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_cse_suffix: /Machine/Microsoft/Windows NT/SecEdit/GptTmpl.inf
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): performing smb operations
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [copy_smb_file_to_gpo_cache] (0x0400): smb_uri: smb://MY_SERVER_FQDN/sysvol/MY_DOMAIN/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}/GPT.INI
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [copy_smb_file_to_gpo_cache] (0x0020): smbc_getFunctionOpen failed [13][Permission denied]
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [perform_smb_operations] (0x0020): copy_smb_file_to_gpo_cache failed [13][Permission denied]
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0020): perform_smb_operations failed.[13][Permission denied].
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0020): gpo_child failed!
(I have replaced real server and domain name by MY_SERVER_FQDN and MY_DOMAIN)
As a workaround, I add new option 'ad_gpo_access_control = permissive' in sssd.conf and authentication is working again, but I'm wondering why upgrade has broken authentication, and what is the impact of the option ?
here is my sssd.conf:
[sssd]
default_domain_suffix = my_domain
full_name_format = %1$s
domains = my_domain
config_file_version = 2
services = nss, pam
[domain/my_domain]
debug_level=9
default_shell = /bin/bash
krb5_store_password_if_offline = True
cache_credentials = True
krb5_realm = MY_DOMAIN
realmd_tags = manages-system joined-with-adcli
id_provider = ad
fallback_homedir = /home/%d/%u
ad_domain = my_domain
use_fully_qualified_names = True
ldap_id_mapping = True
access_provider = ad
After adding 'ad_gpo_access_control = permissive' at the end of file, authentication with samba4 users works again.
Thanks! |
[ Impact ]
A user running a Samba Active Directory Domain Controller compliant with the MS ADTS specifications in regards to how GPO is handled will experience authentication failures when joining an AD realm using the Ubuntu sssd package on Focal, Impish and Jammy with the "fix-gpo-MS-ADTS-compliance.patch" patch applied. Although there is a relatively simple workaround (setting "ad_gpo_access_control = permissive" in /etc/sssd/sssd.conf), we can and should support regular user authentication out of the box.
Upstream sssd has fixed this problem on version 2.7.0, which will be available in Kinetic soon.
[ Test Plan ]
The test case for this bug is a bit complex, but I will do my best to describe it in detail.
We need to setup one VM running a Samba Active Directory Domain Controller (AD DC), which will be our main server. This needs only to be configured once. We then need to setup another VM which will join our AD DC realm using realmd and sssd.
== Virtual Network setup ==
The first step is to create a dedicated virtual network for our tests. This is not strictly mandatory, but it will simplify things. The best way to create this network is via virt-manager. Install it if needed, open the program and select the "QEMU/KVM" line. Go to Edit > Connection Details > Virtual Networks, click on the "+" icon (bottom left), give this network a name (I will use "sssdad"), make sure that "Enable IPv4" and "Enable DHCPv4" are selected (under "IPv4 configuration"). Go to "DNS domain name" and select "Custom". For the domain name, type "test.lan". Click on "Finish".
Take note of the "Device" name that shows up after you create the network. We will use it when creating the VMs. For this test plan, let's assume the device name is "virbr1".
== Samba AD DC VM setup ==
We need to setup a Samba AD DC server. It doesn't matter which Ubuntu release we use for it. Note that we have to use "-n virbr1" when creating the VM, otherwise it won't use our virtual network.
$ lxc launch ubuntu-daily:jammy sambadc -n virbr1 --vm
$ lxc shell sambadc
server# apt update
server# ip a
Make sure to grab this VM's IP address.
server# cat >> /etc/hosts << _EOF_
IP_ADDRESS_HERE sambadc sambadc.test.lan
_EOF_
server# reboot
$ lxc shell sambadc
server# apt install -y samba smbclient winbind libpam-winbind libnss-winbind krb5-kdc libpam-krb5
If you get asked to provide the Default Kerberos version 5 realm, leave the field empty and hit Enter.
server# mv /etc/samba/smb.conf /etc/samba/smb.conf.bkp
server# mv /etc/krb5.conf /etc/krb5.conf.bkp
server# samba-tool domain provision --use-rfc2307 --realm TEST.LAN --domain TEST --server-role dc --dns-backend SAMBA_INTERNAL --adminpass MyPassword1
server# cp /var/lib/samba/private/krb5.conf /etc/
Edit the file /etc/krb5.conf and, under the [libdefaults] section, add the following line:
rdns = false
Save it.
server# systemctl mask smbd.service nmbd.service winbind.service
server# systemctl disable --now smbd.service nmbd.service winbind.service
server# systemctl unmask samba-ad-dc.service
server# systemctl enable --now samba-ad-dc.service
server# systemctl disable --now systemd-resolved.service
server# unlink /etc/resolv.conf
server# cat > /etc/resolv.conf << _EOF_
nameserver 8.8.8.8
search test.lan
_EOF_
server# reboot
This should be enough to configure Samba as an AD DC. While at it, create a test user that will later be used to trigger the bug.
server# samba-tool user create testuser MyUserPassword1
== VM AD client setup ==
Let's configure a VM to act as an AD client.
$ lxc launch ubuntu-daily:jammy sssdclient -n virbr2 --vm
$ lxc shell sssdclient
client# apt update
client# apt install -y sssd-ad sssd-tools realmd adcli sssd-dbus
client# pam-auth-update --enable mkhomedir
We can now check if our container can detect the AD DC:
client# realm -v discover sambadc.test.lan
* Resolving: _ldap._tcp.sambadc.test.lan
* Resolving: sambadc.test.lan
* Performing LDAP DSE lookup on: 192.168.101.142
* Successfully discovered: test.lan
test.lan
type: kerberos
realm-name: TEST.LAN
domain-name: test.lan
configured: no
server-software: active-directory
client-software: sssd
required-package: sssd-tools
required-package: sssd
required-package: libnss-sss
required-package: libpam-sss
required-package: adcli
required-package: samba-common-bin
And we can join the realm:
client# realm -v join sambadc.test.lan
You will be prompted the password for the Administrator user. It is MyPassword1. If everything worked OK, you should now be able to list the information from the Administrator user:
client# getent passwd Administrator@TEST.LAN
administrator@test.lan:*:1522000500:1522000513:Administrator:/home/administrator@test.lan:/bin/bash
== Reproducing the bug ==
Make sure you can obtain the passwd information for the test user we've created in the Samba AD DC server.
client# getent passwd testuser@TEST.LAN
testuser@test.lan:*:1522001104:1522000513:testuser:/home/testuser@test.lan:/bin/bash
Now, try to login as the user:
client# login testuser@TEST.LAN
Password: MyUserPassword1
System error
As can be seen, the user will get a system error when trying to login in a default AD DC setup. In order to confirm that the problem is indeed caused by GPO, the following line can be added to the end of the /etc/sssd/sssd.conf file:
ad_gpo_access_control = permissive
After restarting sssd.service and trying to login again, you can confirm that it succeeds.
[ Where problems could occur ]
TBD.
[ Original Description ]
Hello,
After upgrade of sssd packages from version 2.2.3-3ubuntu0.4 to version 2.2.3-3ubuntu0.6, I could not authenticate with users from my Samba4 directory.
After enabling debug, I can see in /var/log/sssd/gpo_child.log errors:
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): gpo_child started.
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): context initialized
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x0400): cached_gpt_version: -1
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_server length: 21
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_server: smb://MY_SERVER_FQDN
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_share length: 7
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_share: /sysvol
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_path length: 60
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_path: /MY_DOMAIN/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_cse_suffix length: 49
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_cse_suffix: /Machine/Microsoft/Windows NT/SecEdit/GptTmpl.inf
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): performing smb operations
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [copy_smb_file_to_gpo_cache] (0x0400): smb_uri: smb://MY_SERVER_FQDN/sysvol/MY_DOMAIN/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}/GPT.INI
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [copy_smb_file_to_gpo_cache] (0x0020): smbc_getFunctionOpen failed [13][Permission denied]
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [perform_smb_operations] (0x0020): copy_smb_file_to_gpo_cache failed [13][Permission denied]
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0020): perform_smb_operations failed.[13][Permission denied].
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0020): gpo_child failed!
(I have replaced real server and domain name by MY_SERVER_FQDN and MY_DOMAIN)
As a workaround, I add new option 'ad_gpo_access_control = permissive' in sssd.conf and authentication is working again, but I'm wondering why upgrade has broken authentication, and what is the impact of the option ?
here is my sssd.conf:
[sssd]
default_domain_suffix = my_domain
full_name_format = %1$s
domains = my_domain
config_file_version = 2
services = nss, pam
[domain/my_domain]
debug_level=9
default_shell = /bin/bash
krb5_store_password_if_offline = True
cache_credentials = True
krb5_realm = MY_DOMAIN
realmd_tags = manages-system joined-with-adcli
id_provider = ad
fallback_homedir = /home/%d/%u
ad_domain = my_domain
use_fully_qualified_names = True
ldap_id_mapping = True
access_provider = ad
After adding 'ad_gpo_access_control = permissive' at the end of file, authentication with samba4 users works again.
Thanks! |
|
| 2022-06-18 05:08:00 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~sergiodj/ubuntu/+source/sssd/+git/sssd/+merge/424995 |
|
| 2022-06-18 05:10:08 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~sergiodj/ubuntu/+source/sssd/+git/sssd/+merge/424996 |
|
| 2022-06-19 17:00:20 |
Launchpad Janitor |
sssd (Ubuntu Impish): status |
New |
Confirmed |
|
| 2022-06-19 17:01:33 |
Jan Hartkopf |
bug |
|
|
added subscriber Jan Hartkopf |
| 2022-06-20 17:40:50 |
Sergio Durigan Junior |
sssd (Ubuntu Impish): status |
Confirmed |
Won't Fix |
|
| 2022-06-20 17:48:43 |
Sergio Durigan Junior |
description |
[ Impact ]
A user running a Samba Active Directory Domain Controller compliant with the MS ADTS specifications in regards to how GPO is handled will experience authentication failures when joining an AD realm using the Ubuntu sssd package on Focal, Impish and Jammy with the "fix-gpo-MS-ADTS-compliance.patch" patch applied. Although there is a relatively simple workaround (setting "ad_gpo_access_control = permissive" in /etc/sssd/sssd.conf), we can and should support regular user authentication out of the box.
Upstream sssd has fixed this problem on version 2.7.0, which will be available in Kinetic soon.
[ Test Plan ]
The test case for this bug is a bit complex, but I will do my best to describe it in detail.
We need to setup one VM running a Samba Active Directory Domain Controller (AD DC), which will be our main server. This needs only to be configured once. We then need to setup another VM which will join our AD DC realm using realmd and sssd.
== Virtual Network setup ==
The first step is to create a dedicated virtual network for our tests. This is not strictly mandatory, but it will simplify things. The best way to create this network is via virt-manager. Install it if needed, open the program and select the "QEMU/KVM" line. Go to Edit > Connection Details > Virtual Networks, click on the "+" icon (bottom left), give this network a name (I will use "sssdad"), make sure that "Enable IPv4" and "Enable DHCPv4" are selected (under "IPv4 configuration"). Go to "DNS domain name" and select "Custom". For the domain name, type "test.lan". Click on "Finish".
Take note of the "Device" name that shows up after you create the network. We will use it when creating the VMs. For this test plan, let's assume the device name is "virbr1".
== Samba AD DC VM setup ==
We need to setup a Samba AD DC server. It doesn't matter which Ubuntu release we use for it. Note that we have to use "-n virbr1" when creating the VM, otherwise it won't use our virtual network.
$ lxc launch ubuntu-daily:jammy sambadc -n virbr1 --vm
$ lxc shell sambadc
server# apt update
server# ip a
Make sure to grab this VM's IP address.
server# cat >> /etc/hosts << _EOF_
IP_ADDRESS_HERE sambadc sambadc.test.lan
_EOF_
server# reboot
$ lxc shell sambadc
server# apt install -y samba smbclient winbind libpam-winbind libnss-winbind krb5-kdc libpam-krb5
If you get asked to provide the Default Kerberos version 5 realm, leave the field empty and hit Enter.
server# mv /etc/samba/smb.conf /etc/samba/smb.conf.bkp
server# mv /etc/krb5.conf /etc/krb5.conf.bkp
server# samba-tool domain provision --use-rfc2307 --realm TEST.LAN --domain TEST --server-role dc --dns-backend SAMBA_INTERNAL --adminpass MyPassword1
server# cp /var/lib/samba/private/krb5.conf /etc/
Edit the file /etc/krb5.conf and, under the [libdefaults] section, add the following line:
rdns = false
Save it.
server# systemctl mask smbd.service nmbd.service winbind.service
server# systemctl disable --now smbd.service nmbd.service winbind.service
server# systemctl unmask samba-ad-dc.service
server# systemctl enable --now samba-ad-dc.service
server# systemctl disable --now systemd-resolved.service
server# unlink /etc/resolv.conf
server# cat > /etc/resolv.conf << _EOF_
nameserver 8.8.8.8
search test.lan
_EOF_
server# reboot
This should be enough to configure Samba as an AD DC. While at it, create a test user that will later be used to trigger the bug.
server# samba-tool user create testuser MyUserPassword1
== VM AD client setup ==
Let's configure a VM to act as an AD client.
$ lxc launch ubuntu-daily:jammy sssdclient -n virbr2 --vm
$ lxc shell sssdclient
client# apt update
client# apt install -y sssd-ad sssd-tools realmd adcli sssd-dbus
client# pam-auth-update --enable mkhomedir
We can now check if our container can detect the AD DC:
client# realm -v discover sambadc.test.lan
* Resolving: _ldap._tcp.sambadc.test.lan
* Resolving: sambadc.test.lan
* Performing LDAP DSE lookup on: 192.168.101.142
* Successfully discovered: test.lan
test.lan
type: kerberos
realm-name: TEST.LAN
domain-name: test.lan
configured: no
server-software: active-directory
client-software: sssd
required-package: sssd-tools
required-package: sssd
required-package: libnss-sss
required-package: libpam-sss
required-package: adcli
required-package: samba-common-bin
And we can join the realm:
client# realm -v join sambadc.test.lan
You will be prompted the password for the Administrator user. It is MyPassword1. If everything worked OK, you should now be able to list the information from the Administrator user:
client# getent passwd Administrator@TEST.LAN
administrator@test.lan:*:1522000500:1522000513:Administrator:/home/administrator@test.lan:/bin/bash
== Reproducing the bug ==
Make sure you can obtain the passwd information for the test user we've created in the Samba AD DC server.
client# getent passwd testuser@TEST.LAN
testuser@test.lan:*:1522001104:1522000513:testuser:/home/testuser@test.lan:/bin/bash
Now, try to login as the user:
client# login testuser@TEST.LAN
Password: MyUserPassword1
System error
As can be seen, the user will get a system error when trying to login in a default AD DC setup. In order to confirm that the problem is indeed caused by GPO, the following line can be added to the end of the /etc/sssd/sssd.conf file:
ad_gpo_access_control = permissive
After restarting sssd.service and trying to login again, you can confirm that it succeeds.
[ Where problems could occur ]
TBD.
[ Original Description ]
Hello,
After upgrade of sssd packages from version 2.2.3-3ubuntu0.4 to version 2.2.3-3ubuntu0.6, I could not authenticate with users from my Samba4 directory.
After enabling debug, I can see in /var/log/sssd/gpo_child.log errors:
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): gpo_child started.
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): context initialized
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x0400): cached_gpt_version: -1
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_server length: 21
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_server: smb://MY_SERVER_FQDN
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_share length: 7
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_share: /sysvol
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_path length: 60
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_path: /MY_DOMAIN/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_cse_suffix length: 49
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_cse_suffix: /Machine/Microsoft/Windows NT/SecEdit/GptTmpl.inf
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): performing smb operations
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [copy_smb_file_to_gpo_cache] (0x0400): smb_uri: smb://MY_SERVER_FQDN/sysvol/MY_DOMAIN/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}/GPT.INI
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [copy_smb_file_to_gpo_cache] (0x0020): smbc_getFunctionOpen failed [13][Permission denied]
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [perform_smb_operations] (0x0020): copy_smb_file_to_gpo_cache failed [13][Permission denied]
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0020): perform_smb_operations failed.[13][Permission denied].
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0020): gpo_child failed!
(I have replaced real server and domain name by MY_SERVER_FQDN and MY_DOMAIN)
As a workaround, I add new option 'ad_gpo_access_control = permissive' in sssd.conf and authentication is working again, but I'm wondering why upgrade has broken authentication, and what is the impact of the option ?
here is my sssd.conf:
[sssd]
default_domain_suffix = my_domain
full_name_format = %1$s
domains = my_domain
config_file_version = 2
services = nss, pam
[domain/my_domain]
debug_level=9
default_shell = /bin/bash
krb5_store_password_if_offline = True
cache_credentials = True
krb5_realm = MY_DOMAIN
realmd_tags = manages-system joined-with-adcli
id_provider = ad
fallback_homedir = /home/%d/%u
ad_domain = my_domain
use_fully_qualified_names = True
ldap_id_mapping = True
access_provider = ad
After adding 'ad_gpo_access_control = permissive' at the end of file, authentication with samba4 users works again.
Thanks! |
[ Impact ]
A user running a Samba Active Directory Domain Controller compliant with the MS ADTS specifications in regards to how GPO is handled will experience authentication failures when joining an AD realm using the Ubuntu sssd package on Focal, Impish and Jammy with the "fix-gpo-MS-ADTS-compliance.patch" patch applied. Although there is a relatively simple workaround (setting "ad_gpo_access_control = permissive" in /etc/sssd/sssd.conf), we can and should support regular user authentication out of the box.
Upstream sssd has fixed this problem on version 2.7.0, which will be available in Kinetic soon.
[ Test Plan ]
The test case for this bug is a bit complex, but I will do my best to describe it in detail.
We need to setup one VM running a Samba Active Directory Domain Controller (AD DC), which will be our main server. This needs only to be configured once. We then need to setup another VM which will join our AD DC realm using realmd and sssd.
== Virtual Network setup ==
The first step is to create a dedicated virtual network for our tests. This is not strictly mandatory, but it will simplify things. The best way to create this network is via virt-manager. Install it if needed, open the program and select the "QEMU/KVM" line. Go to Edit > Connection Details > Virtual Networks, click on the "+" icon (bottom left), give this network a name (I will use "sssdad"), make sure that "Enable IPv4" and "Enable DHCPv4" are selected (under "IPv4 configuration"). Go to "DNS domain name" and select "Custom". For the domain name, type "test.lan". Click on "Finish".
Take note of the "Device" name that shows up after you create the network. We will use it when creating the VMs. For this test plan, let's assume the device name is "virbr1".
== Samba AD DC VM setup ==
We need to setup a Samba AD DC server. It doesn't matter which Ubuntu release we use for it. Note that we have to use "-n virbr1" when creating the VM, otherwise it won't use our virtual network.
$ lxc launch ubuntu-daily:jammy sambadc -n virbr1 --vm
$ lxc shell sambadc
server# apt update
server# ip a
Make sure to grab this VM's IP address.
server# cat >> /etc/hosts << _EOF_
IP_ADDRESS_HERE sambadc sambadc.test.lan
_EOF_
server# reboot
$ lxc shell sambadc
server# apt install -y samba smbclient winbind libpam-winbind libnss-winbind krb5-kdc libpam-krb5
If you get asked to provide the Default Kerberos version 5 realm, leave the field empty and hit Enter.
server# mv /etc/samba/smb.conf /etc/samba/smb.conf.bkp
server# mv /etc/krb5.conf /etc/krb5.conf.bkp
server# samba-tool domain provision --use-rfc2307 --realm TEST.LAN --domain TEST --server-role dc --dns-backend SAMBA_INTERNAL --adminpass MyPassword1
server# cp /var/lib/samba/private/krb5.conf /etc/
Edit the file /etc/krb5.conf and, under the [libdefaults] section, add the following line:
rdns = false
Save it.
server# systemctl mask smbd.service nmbd.service winbind.service
server# systemctl disable --now smbd.service nmbd.service winbind.service
server# systemctl unmask samba-ad-dc.service
server# systemctl enable --now samba-ad-dc.service
server# systemctl disable --now systemd-resolved.service
server# unlink /etc/resolv.conf
server# cat > /etc/resolv.conf << _EOF_
nameserver 8.8.8.8
search test.lan
_EOF_
server# reboot
This should be enough to configure Samba as an AD DC. While at it, create a test user that will later be used to trigger the bug.
server# samba-tool user create testuser MyUserPassword1
== VM AD client setup ==
Let's configure a VM to act as an AD client.
$ lxc launch ubuntu-daily:jammy sssdclient -n virbr2 --vm
$ lxc shell sssdclient
client# apt update
client# apt install -y sssd-ad sssd-tools realmd adcli sssd-dbus
client# pam-auth-update --enable mkhomedir
We can now check if our container can detect the AD DC:
client# realm -v discover sambadc.test.lan
* Resolving: _ldap._tcp.sambadc.test.lan
* Resolving: sambadc.test.lan
* Performing LDAP DSE lookup on: 192.168.101.142
* Successfully discovered: test.lan
test.lan
type: kerberos
realm-name: TEST.LAN
domain-name: test.lan
configured: no
server-software: active-directory
client-software: sssd
required-package: sssd-tools
required-package: sssd
required-package: libnss-sss
required-package: libpam-sss
required-package: adcli
required-package: samba-common-bin
And we can join the realm:
client# realm -v join sambadc.test.lan
You will be prompted the password for the Administrator user. It is MyPassword1. If everything worked OK, you should now be able to list the information from the Administrator user:
client# getent passwd Administrator@TEST.LAN
administrator@test.lan:*:1522000500:1522000513:Administrator:/home/administrator@test.lan:/bin/bash
== Reproducing the bug ==
Make sure you can obtain the passwd information for the test user we've created in the Samba AD DC server.
client# getent passwd testuser@TEST.LAN
testuser@test.lan:*:1522001104:1522000513:testuser:/home/testuser@test.lan:/bin/bash
Now, try to login as the user:
client# login testuser@TEST.LAN
Password: MyUserPassword1
System error
As can be seen, the user will get a system error when trying to login in a default AD DC setup. In order to confirm that the problem is indeed caused by GPO, the following line can be added to the end of the /etc/sssd/sssd.conf file:
ad_gpo_access_control = permissive
After restarting sssd.service and trying to login again, you can confirm that it succeeds.
[ Where problems could occur ]
The behaviour being introduced by this change goes against the specificiation for Group Policies by Microsoft. It is worth mentioning that Microsoft Windows itself does *not* follow the specification either, so in a way we are bringing sssd to the "de facto" standard. But users can be surprised to see the authentication process successfully finish even if there is no SecEdit\GptTmpl.inf available.
As usual, there is also the small risk of rebuilding a package against newer dependencies in the archive.
[ Original Description ]
Hello,
After upgrade of sssd packages from version 2.2.3-3ubuntu0.4 to version 2.2.3-3ubuntu0.6, I could not authenticate with users from my Samba4 directory.
After enabling debug, I can see in /var/log/sssd/gpo_child.log errors:
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): gpo_child started.
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): context initialized
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x0400): cached_gpt_version: -1
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_server length: 21
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_server: smb://MY_SERVER_FQDN
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_share length: 7
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_share: /sysvol
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_path length: 60
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_path: /MY_DOMAIN/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_cse_suffix length: 49
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_cse_suffix: /Machine/Microsoft/Windows NT/SecEdit/GptTmpl.inf
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): performing smb operations
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [copy_smb_file_to_gpo_cache] (0x0400): smb_uri: smb://MY_SERVER_FQDN/sysvol/MY_DOMAIN/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}/GPT.INI
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [copy_smb_file_to_gpo_cache] (0x0020): smbc_getFunctionOpen failed [13][Permission denied]
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [perform_smb_operations] (0x0020): copy_smb_file_to_gpo_cache failed [13][Permission denied]
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0020): perform_smb_operations failed.[13][Permission denied].
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0020): gpo_child failed!
(I have replaced real server and domain name by MY_SERVER_FQDN and MY_DOMAIN)
As a workaround, I add new option 'ad_gpo_access_control = permissive' in sssd.conf and authentication is working again, but I'm wondering why upgrade has broken authentication, and what is the impact of the option ?
here is my sssd.conf:
[sssd]
default_domain_suffix = my_domain
full_name_format = %1$s
domains = my_domain
config_file_version = 2
services = nss, pam
[domain/my_domain]
debug_level=9
default_shell = /bin/bash
krb5_store_password_if_offline = True
cache_credentials = True
krb5_realm = MY_DOMAIN
realmd_tags = manages-system joined-with-adcli
id_provider = ad
fallback_homedir = /home/%d/%u
ad_domain = my_domain
use_fully_qualified_names = True
ldap_id_mapping = True
access_provider = ad
After adding 'ad_gpo_access_control = permissive' at the end of file, authentication with samba4 users works again.
Thanks! |
|
| 2022-06-21 14:19:46 |
Sergio Durigan Junior |
description |
[ Impact ]
A user running a Samba Active Directory Domain Controller compliant with the MS ADTS specifications in regards to how GPO is handled will experience authentication failures when joining an AD realm using the Ubuntu sssd package on Focal, Impish and Jammy with the "fix-gpo-MS-ADTS-compliance.patch" patch applied. Although there is a relatively simple workaround (setting "ad_gpo_access_control = permissive" in /etc/sssd/sssd.conf), we can and should support regular user authentication out of the box.
Upstream sssd has fixed this problem on version 2.7.0, which will be available in Kinetic soon.
[ Test Plan ]
The test case for this bug is a bit complex, but I will do my best to describe it in detail.
We need to setup one VM running a Samba Active Directory Domain Controller (AD DC), which will be our main server. This needs only to be configured once. We then need to setup another VM which will join our AD DC realm using realmd and sssd.
== Virtual Network setup ==
The first step is to create a dedicated virtual network for our tests. This is not strictly mandatory, but it will simplify things. The best way to create this network is via virt-manager. Install it if needed, open the program and select the "QEMU/KVM" line. Go to Edit > Connection Details > Virtual Networks, click on the "+" icon (bottom left), give this network a name (I will use "sssdad"), make sure that "Enable IPv4" and "Enable DHCPv4" are selected (under "IPv4 configuration"). Go to "DNS domain name" and select "Custom". For the domain name, type "test.lan". Click on "Finish".
Take note of the "Device" name that shows up after you create the network. We will use it when creating the VMs. For this test plan, let's assume the device name is "virbr1".
== Samba AD DC VM setup ==
We need to setup a Samba AD DC server. It doesn't matter which Ubuntu release we use for it. Note that we have to use "-n virbr1" when creating the VM, otherwise it won't use our virtual network.
$ lxc launch ubuntu-daily:jammy sambadc -n virbr1 --vm
$ lxc shell sambadc
server# apt update
server# ip a
Make sure to grab this VM's IP address.
server# cat >> /etc/hosts << _EOF_
IP_ADDRESS_HERE sambadc sambadc.test.lan
_EOF_
server# reboot
$ lxc shell sambadc
server# apt install -y samba smbclient winbind libpam-winbind libnss-winbind krb5-kdc libpam-krb5
If you get asked to provide the Default Kerberos version 5 realm, leave the field empty and hit Enter.
server# mv /etc/samba/smb.conf /etc/samba/smb.conf.bkp
server# mv /etc/krb5.conf /etc/krb5.conf.bkp
server# samba-tool domain provision --use-rfc2307 --realm TEST.LAN --domain TEST --server-role dc --dns-backend SAMBA_INTERNAL --adminpass MyPassword1
server# cp /var/lib/samba/private/krb5.conf /etc/
Edit the file /etc/krb5.conf and, under the [libdefaults] section, add the following line:
rdns = false
Save it.
server# systemctl mask smbd.service nmbd.service winbind.service
server# systemctl disable --now smbd.service nmbd.service winbind.service
server# systemctl unmask samba-ad-dc.service
server# systemctl enable --now samba-ad-dc.service
server# systemctl disable --now systemd-resolved.service
server# unlink /etc/resolv.conf
server# cat > /etc/resolv.conf << _EOF_
nameserver 8.8.8.8
search test.lan
_EOF_
server# reboot
This should be enough to configure Samba as an AD DC. While at it, create a test user that will later be used to trigger the bug.
server# samba-tool user create testuser MyUserPassword1
== VM AD client setup ==
Let's configure a VM to act as an AD client.
$ lxc launch ubuntu-daily:jammy sssdclient -n virbr2 --vm
$ lxc shell sssdclient
client# apt update
client# apt install -y sssd-ad sssd-tools realmd adcli sssd-dbus
client# pam-auth-update --enable mkhomedir
We can now check if our container can detect the AD DC:
client# realm -v discover sambadc.test.lan
* Resolving: _ldap._tcp.sambadc.test.lan
* Resolving: sambadc.test.lan
* Performing LDAP DSE lookup on: 192.168.101.142
* Successfully discovered: test.lan
test.lan
type: kerberos
realm-name: TEST.LAN
domain-name: test.lan
configured: no
server-software: active-directory
client-software: sssd
required-package: sssd-tools
required-package: sssd
required-package: libnss-sss
required-package: libpam-sss
required-package: adcli
required-package: samba-common-bin
And we can join the realm:
client# realm -v join sambadc.test.lan
You will be prompted the password for the Administrator user. It is MyPassword1. If everything worked OK, you should now be able to list the information from the Administrator user:
client# getent passwd Administrator@TEST.LAN
administrator@test.lan:*:1522000500:1522000513:Administrator:/home/administrator@test.lan:/bin/bash
== Reproducing the bug ==
Make sure you can obtain the passwd information for the test user we've created in the Samba AD DC server.
client# getent passwd testuser@TEST.LAN
testuser@test.lan:*:1522001104:1522000513:testuser:/home/testuser@test.lan:/bin/bash
Now, try to login as the user:
client# login testuser@TEST.LAN
Password: MyUserPassword1
System error
As can be seen, the user will get a system error when trying to login in a default AD DC setup. In order to confirm that the problem is indeed caused by GPO, the following line can be added to the end of the /etc/sssd/sssd.conf file:
ad_gpo_access_control = permissive
After restarting sssd.service and trying to login again, you can confirm that it succeeds.
[ Where problems could occur ]
The behaviour being introduced by this change goes against the specificiation for Group Policies by Microsoft. It is worth mentioning that Microsoft Windows itself does *not* follow the specification either, so in a way we are bringing sssd to the "de facto" standard. But users can be surprised to see the authentication process successfully finish even if there is no SecEdit\GptTmpl.inf available.
As usual, there is also the small risk of rebuilding a package against newer dependencies in the archive.
[ Original Description ]
Hello,
After upgrade of sssd packages from version 2.2.3-3ubuntu0.4 to version 2.2.3-3ubuntu0.6, I could not authenticate with users from my Samba4 directory.
After enabling debug, I can see in /var/log/sssd/gpo_child.log errors:
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): gpo_child started.
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): context initialized
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x0400): cached_gpt_version: -1
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_server length: 21
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_server: smb://MY_SERVER_FQDN
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_share length: 7
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_share: /sysvol
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_path length: 60
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_path: /MY_DOMAIN/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_cse_suffix length: 49
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_cse_suffix: /Machine/Microsoft/Windows NT/SecEdit/GptTmpl.inf
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): performing smb operations
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [copy_smb_file_to_gpo_cache] (0x0400): smb_uri: smb://MY_SERVER_FQDN/sysvol/MY_DOMAIN/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}/GPT.INI
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [copy_smb_file_to_gpo_cache] (0x0020): smbc_getFunctionOpen failed [13][Permission denied]
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [perform_smb_operations] (0x0020): copy_smb_file_to_gpo_cache failed [13][Permission denied]
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0020): perform_smb_operations failed.[13][Permission denied].
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0020): gpo_child failed!
(I have replaced real server and domain name by MY_SERVER_FQDN and MY_DOMAIN)
As a workaround, I add new option 'ad_gpo_access_control = permissive' in sssd.conf and authentication is working again, but I'm wondering why upgrade has broken authentication, and what is the impact of the option ?
here is my sssd.conf:
[sssd]
default_domain_suffix = my_domain
full_name_format = %1$s
domains = my_domain
config_file_version = 2
services = nss, pam
[domain/my_domain]
debug_level=9
default_shell = /bin/bash
krb5_store_password_if_offline = True
cache_credentials = True
krb5_realm = MY_DOMAIN
realmd_tags = manages-system joined-with-adcli
id_provider = ad
fallback_homedir = /home/%d/%u
ad_domain = my_domain
use_fully_qualified_names = True
ldap_id_mapping = True
access_provider = ad
After adding 'ad_gpo_access_control = permissive' at the end of file, authentication with samba4 users works again.
Thanks! |
[ Impact ]
A user running a Samba Active Directory Domain Controller compliant with the MS ADTS specifications in regards to how GPO is handled will experience authentication failures when joining an AD realm using the Ubuntu sssd package on Focal, Impish and Jammy with the "fix-gpo-MS-ADTS-compliance.patch" patch applied. Although there is a relatively simple workaround (setting "ad_gpo_access_control = permissive" in /etc/sssd/sssd.conf), we can and should support regular user authentication out of the box.
Upstream sssd has fixed this problem on version 2.7.0, which will be available in Kinetic soon.
[ Test Plan ]
The test case for this bug is a bit complex, but I will do my best to describe it in detail.
We need to setup one VM running a Samba Active Directory Domain Controller (AD DC), which will be our main server. This needs only to be configured once. We then need to setup another VM which will join our AD DC realm using realmd and sssd.
== Virtual Network setup ==
The first step is to create a dedicated virtual network for our tests. This is not strictly mandatory, but it will simplify things. The best way to create this network is via virt-manager. Install it if needed, open the program and select the "QEMU/KVM" line. Go to Edit > Connection Details > Virtual Networks, click on the "+" icon (bottom left), give this network a name (I will use "sssdad"), make sure that "Enable IPv4" and "Enable DHCPv4" are selected (under "IPv4 configuration"). Go to "DNS domain name" and select "Custom". For the domain name, type "test.lan". Click on "Finish".
Take note of the "Device" name that shows up after you create the network. We will use it when creating the VMs. For this test plan, let's assume the device name is "virbr1".
== Samba AD DC VM setup ==
We need to setup a Samba AD DC server. It doesn't matter which Ubuntu release we use for it. Note that we have to use "-n virbr1" when creating the VM, otherwise it won't use our virtual network.
$ lxc launch ubuntu-daily:jammy sambadc -n virbr1 --vm
$ lxc shell sambadc
server# apt update
server# ip a
Make sure to grab this VM's IP address.
server# cat >> /etc/hosts << _EOF_
IP_ADDRESS_HERE sambadc sambadc.test.lan
_EOF_
server# reboot
$ lxc shell sambadc
server# apt install -y samba winbind
server# mv /etc/samba/smb.conf /etc/samba/smb.conf.bkp
server# samba-tool domain provision --use-rfc2307 --realm TEST.LAN --domain TEST --server-role dc --dns-backend SAMBA_INTERNAL --adminpass MyPassword1
server# systemctl mask smbd.service nmbd.service winbind.service
server# systemctl disable --now smbd.service nmbd.service winbind.service
server# systemctl unmask samba-ad-dc.service
server# systemctl enable --now samba-ad-dc.service
server# systemctl disable --now systemd-resolved.service
server# unlink /etc/resolv.conf
server# cat > /etc/resolv.conf << _EOF_
nameserver 8.8.8.8
search test.lan
_EOF_
server# reboot
This should be enough to configure Samba as an AD DC. While at it, create a test user that will later be used to trigger the bug.
server# samba-tool user create testuser MyUserPassword1
== VM AD client setup ==
Let's configure a VM to act as an AD client.
$ lxc launch ubuntu-daily:jammy sssdclient -n virbr2 --vm
$ lxc shell sssdclient
client# apt update
client# apt install -y sssd-ad sssd-tools realmd adcli sssd-dbus
client# pam-auth-update --enable mkhomedir
We can now check if our container can detect the AD DC:
client# realm -v discover sambadc.test.lan
* Resolving: _ldap._tcp.sambadc.test.lan
* Resolving: sambadc.test.lan
* Performing LDAP DSE lookup on: 192.168.101.142
* Successfully discovered: test.lan
test.lan
type: kerberos
realm-name: TEST.LAN
domain-name: test.lan
configured: no
server-software: active-directory
client-software: sssd
required-package: sssd-tools
required-package: sssd
required-package: libnss-sss
required-package: libpam-sss
required-package: adcli
required-package: samba-common-bin
And we can join the realm:
client# realm -v join sambadc.test.lan
You will be prompted the password for the Administrator user. It is MyPassword1. If everything worked OK, you should now be able to list the information from the Administrator user:
client# getent passwd Administrator@TEST.LAN
administrator@test.lan:*:1522000500:1522000513:Administrator:/home/administrator@test.lan:/bin/bash
== Reproducing the bug ==
Make sure you can obtain the passwd information for the test user we've created in the Samba AD DC server.
client# getent passwd testuser@TEST.LAN
testuser@test.lan:*:1522001104:1522000513:testuser:/home/testuser@test.lan:/bin/bash
Now, try to login as the user:
client# login testuser@TEST.LAN
Password: MyUserPassword1
System error
As can be seen, the user will get a system error when trying to login in a default AD DC setup. In order to confirm that the problem is indeed caused by GPO, the following line can be added to the end of the /etc/sssd/sssd.conf file:
ad_gpo_access_control = permissive
After restarting sssd.service and trying to login again, you can confirm that it succeeds.
[ Where problems could occur ]
The behaviour being introduced by this change goes against the specificiation for Group Policies by Microsoft. It is worth mentioning that Microsoft Windows itself does *not* follow the specification either, so in a way we are bringing sssd to the "de facto" standard. But users can be surprised to see the authentication process successfully finish even if there is no SecEdit\GptTmpl.inf available.
As usual, there is also the small risk of rebuilding a package against newer dependencies in the archive.
[ Original Description ]
Hello,
After upgrade of sssd packages from version 2.2.3-3ubuntu0.4 to version 2.2.3-3ubuntu0.6, I could not authenticate with users from my Samba4 directory.
After enabling debug, I can see in /var/log/sssd/gpo_child.log errors:
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): gpo_child started.
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): context initialized
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x0400): cached_gpt_version: -1
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_server length: 21
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_server: smb://MY_SERVER_FQDN
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_share length: 7
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_share: /sysvol
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_path length: 60
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_path: /MY_DOMAIN/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_cse_suffix length: 49
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_cse_suffix: /Machine/Microsoft/Windows NT/SecEdit/GptTmpl.inf
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): performing smb operations
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [copy_smb_file_to_gpo_cache] (0x0400): smb_uri: smb://MY_SERVER_FQDN/sysvol/MY_DOMAIN/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}/GPT.INI
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [copy_smb_file_to_gpo_cache] (0x0020): smbc_getFunctionOpen failed [13][Permission denied]
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [perform_smb_operations] (0x0020): copy_smb_file_to_gpo_cache failed [13][Permission denied]
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0020): perform_smb_operations failed.[13][Permission denied].
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0020): gpo_child failed!
(I have replaced real server and domain name by MY_SERVER_FQDN and MY_DOMAIN)
As a workaround, I add new option 'ad_gpo_access_control = permissive' in sssd.conf and authentication is working again, but I'm wondering why upgrade has broken authentication, and what is the impact of the option ?
here is my sssd.conf:
[sssd]
default_domain_suffix = my_domain
full_name_format = %1$s
domains = my_domain
config_file_version = 2
services = nss, pam
[domain/my_domain]
debug_level=9
default_shell = /bin/bash
krb5_store_password_if_offline = True
cache_credentials = True
krb5_realm = MY_DOMAIN
realmd_tags = manages-system joined-with-adcli
id_provider = ad
fallback_homedir = /home/%d/%u
ad_domain = my_domain
use_fully_qualified_names = True
ldap_id_mapping = True
access_provider = ad
After adding 'ad_gpo_access_control = permissive' at the end of file, authentication with samba4 users works again.
Thanks! |
|
| 2022-06-21 17:27:00 |
Sergio Durigan Junior |
description |
[ Impact ]
A user running a Samba Active Directory Domain Controller compliant with the MS ADTS specifications in regards to how GPO is handled will experience authentication failures when joining an AD realm using the Ubuntu sssd package on Focal, Impish and Jammy with the "fix-gpo-MS-ADTS-compliance.patch" patch applied. Although there is a relatively simple workaround (setting "ad_gpo_access_control = permissive" in /etc/sssd/sssd.conf), we can and should support regular user authentication out of the box.
Upstream sssd has fixed this problem on version 2.7.0, which will be available in Kinetic soon.
[ Test Plan ]
The test case for this bug is a bit complex, but I will do my best to describe it in detail.
We need to setup one VM running a Samba Active Directory Domain Controller (AD DC), which will be our main server. This needs only to be configured once. We then need to setup another VM which will join our AD DC realm using realmd and sssd.
== Virtual Network setup ==
The first step is to create a dedicated virtual network for our tests. This is not strictly mandatory, but it will simplify things. The best way to create this network is via virt-manager. Install it if needed, open the program and select the "QEMU/KVM" line. Go to Edit > Connection Details > Virtual Networks, click on the "+" icon (bottom left), give this network a name (I will use "sssdad"), make sure that "Enable IPv4" and "Enable DHCPv4" are selected (under "IPv4 configuration"). Go to "DNS domain name" and select "Custom". For the domain name, type "test.lan". Click on "Finish".
Take note of the "Device" name that shows up after you create the network. We will use it when creating the VMs. For this test plan, let's assume the device name is "virbr1".
== Samba AD DC VM setup ==
We need to setup a Samba AD DC server. It doesn't matter which Ubuntu release we use for it. Note that we have to use "-n virbr1" when creating the VM, otherwise it won't use our virtual network.
$ lxc launch ubuntu-daily:jammy sambadc -n virbr1 --vm
$ lxc shell sambadc
server# apt update
server# ip a
Make sure to grab this VM's IP address.
server# cat >> /etc/hosts << _EOF_
IP_ADDRESS_HERE sambadc sambadc.test.lan
_EOF_
server# reboot
$ lxc shell sambadc
server# apt install -y samba winbind
server# mv /etc/samba/smb.conf /etc/samba/smb.conf.bkp
server# samba-tool domain provision --use-rfc2307 --realm TEST.LAN --domain TEST --server-role dc --dns-backend SAMBA_INTERNAL --adminpass MyPassword1
server# systemctl mask smbd.service nmbd.service winbind.service
server# systemctl disable --now smbd.service nmbd.service winbind.service
server# systemctl unmask samba-ad-dc.service
server# systemctl enable --now samba-ad-dc.service
server# systemctl disable --now systemd-resolved.service
server# unlink /etc/resolv.conf
server# cat > /etc/resolv.conf << _EOF_
nameserver 8.8.8.8
search test.lan
_EOF_
server# reboot
This should be enough to configure Samba as an AD DC. While at it, create a test user that will later be used to trigger the bug.
server# samba-tool user create testuser MyUserPassword1
== VM AD client setup ==
Let's configure a VM to act as an AD client.
$ lxc launch ubuntu-daily:jammy sssdclient -n virbr2 --vm
$ lxc shell sssdclient
client# apt update
client# apt install -y sssd-ad sssd-tools realmd adcli sssd-dbus
client# pam-auth-update --enable mkhomedir
We can now check if our container can detect the AD DC:
client# realm -v discover sambadc.test.lan
* Resolving: _ldap._tcp.sambadc.test.lan
* Resolving: sambadc.test.lan
* Performing LDAP DSE lookup on: 192.168.101.142
* Successfully discovered: test.lan
test.lan
type: kerberos
realm-name: TEST.LAN
domain-name: test.lan
configured: no
server-software: active-directory
client-software: sssd
required-package: sssd-tools
required-package: sssd
required-package: libnss-sss
required-package: libpam-sss
required-package: adcli
required-package: samba-common-bin
And we can join the realm:
client# realm -v join sambadc.test.lan
You will be prompted the password for the Administrator user. It is MyPassword1. If everything worked OK, you should now be able to list the information from the Administrator user:
client# getent passwd Administrator@TEST.LAN
administrator@test.lan:*:1522000500:1522000513:Administrator:/home/administrator@test.lan:/bin/bash
== Reproducing the bug ==
Make sure you can obtain the passwd information for the test user we've created in the Samba AD DC server.
client# getent passwd testuser@TEST.LAN
testuser@test.lan:*:1522001104:1522000513:testuser:/home/testuser@test.lan:/bin/bash
Now, try to login as the user:
client# login testuser@TEST.LAN
Password: MyUserPassword1
System error
As can be seen, the user will get a system error when trying to login in a default AD DC setup. In order to confirm that the problem is indeed caused by GPO, the following line can be added to the end of the /etc/sssd/sssd.conf file:
ad_gpo_access_control = permissive
After restarting sssd.service and trying to login again, you can confirm that it succeeds.
[ Where problems could occur ]
The behaviour being introduced by this change goes against the specificiation for Group Policies by Microsoft. It is worth mentioning that Microsoft Windows itself does *not* follow the specification either, so in a way we are bringing sssd to the "de facto" standard. But users can be surprised to see the authentication process successfully finish even if there is no SecEdit\GptTmpl.inf available.
As usual, there is also the small risk of rebuilding a package against newer dependencies in the archive.
[ Original Description ]
Hello,
After upgrade of sssd packages from version 2.2.3-3ubuntu0.4 to version 2.2.3-3ubuntu0.6, I could not authenticate with users from my Samba4 directory.
After enabling debug, I can see in /var/log/sssd/gpo_child.log errors:
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): gpo_child started.
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): context initialized
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x0400): cached_gpt_version: -1
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_server length: 21
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_server: smb://MY_SERVER_FQDN
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_share length: 7
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_share: /sysvol
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_path length: 60
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_path: /MY_DOMAIN/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_cse_suffix length: 49
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_cse_suffix: /Machine/Microsoft/Windows NT/SecEdit/GptTmpl.inf
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): performing smb operations
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [copy_smb_file_to_gpo_cache] (0x0400): smb_uri: smb://MY_SERVER_FQDN/sysvol/MY_DOMAIN/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}/GPT.INI
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [copy_smb_file_to_gpo_cache] (0x0020): smbc_getFunctionOpen failed [13][Permission denied]
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [perform_smb_operations] (0x0020): copy_smb_file_to_gpo_cache failed [13][Permission denied]
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0020): perform_smb_operations failed.[13][Permission denied].
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0020): gpo_child failed!
(I have replaced real server and domain name by MY_SERVER_FQDN and MY_DOMAIN)
As a workaround, I add new option 'ad_gpo_access_control = permissive' in sssd.conf and authentication is working again, but I'm wondering why upgrade has broken authentication, and what is the impact of the option ?
here is my sssd.conf:
[sssd]
default_domain_suffix = my_domain
full_name_format = %1$s
domains = my_domain
config_file_version = 2
services = nss, pam
[domain/my_domain]
debug_level=9
default_shell = /bin/bash
krb5_store_password_if_offline = True
cache_credentials = True
krb5_realm = MY_DOMAIN
realmd_tags = manages-system joined-with-adcli
id_provider = ad
fallback_homedir = /home/%d/%u
ad_domain = my_domain
use_fully_qualified_names = True
ldap_id_mapping = True
access_provider = ad
After adding 'ad_gpo_access_control = permissive' at the end of file, authentication with samba4 users works again.
Thanks! |
[ Impact ]
A user running a Samba Active Directory Domain Controller compliant with the MS ADTS specifications in regards to how GPO is handled will experience authentication failures when joining an AD realm using the Ubuntu sssd package on Focal, Impish and Jammy with the "fix-gpo-MS-ADTS-compliance.patch" patch applied. Although there is a relatively simple workaround (setting "ad_gpo_access_control = permissive" in /etc/sssd/sssd.conf), we can and should support regular user authentication out of the box.
Upstream sssd has fixed this problem on version 2.7.0, which will be available in Kinetic soon.
[ Test Plan ]
The test case for this bug is a bit complex, but I will do my best to describe it in detail.
We need to setup one VM running a Samba Active Directory Domain Controller (AD DC), which will be our main server. This needs only to be configured once. We then need to setup another VM which will join our AD DC realm using realmd and sssd.
== Virtual Network setup ==
The first step is to create a dedicated virtual network for our tests. This is not strictly mandatory, but it will simplify things. The best way to create this network is via virt-manager. Install it if needed, open the program and select the "QEMU/KVM" line. Go to Edit > Connection Details > Virtual Networks, click on the "+" icon (bottom left), give this network a name (I will use "sssdad"), make sure that "Enable IPv4" and "Enable DHCPv4" are selected (under "IPv4 configuration"). Go to "DNS domain name" and select "Custom". For the domain name, type "test.lan". Click on "Finish".
Take note of the "Device" name that shows up after you create the network. We will use it when creating the VMs. For this test plan, let's assume the device name is "virbr1".
== Samba AD DC VM setup ==
We need to setup a Samba AD DC server. It doesn't matter which Ubuntu release we use for it. Note that we have to use "-n virbr1" when creating the VM, otherwise it won't use our virtual network.
$ lxc launch ubuntu-daily:jammy sambadc -n virbr1 --vm
$ lxc shell sambadc
server# apt update
server# ip a
Make sure to grab this VM's IP address.
server# cat >> /etc/hosts << _EOF_
IP_ADDRESS_HERE sambadc sambadc.test.lan
_EOF_
server# reboot
$ lxc shell sambadc
server# apt install -y samba winbind
server# mv /etc/samba/smb.conf /etc/samba/smb.conf.bkp
server# samba-tool domain provision --use-rfc2307 --realm TEST.LAN --domain TEST --server-role dc --dns-backend SAMBA_INTERNAL --adminpass MyPassword1
server# systemctl mask smbd.service nmbd.service winbind.service
server# systemctl disable --now smbd.service nmbd.service winbind.service
server# systemctl unmask samba-ad-dc.service
server# systemctl enable --now samba-ad-dc.service
We now have to adjust the DNS server settings of the server. We are going to disable systemd-resolved.service and use samba as our DNS service.
You will notice that the samba-tool command issued above has added 127.0.0.53 as the "dns forwarder" in /etc/samba/smb.conf. Edit the file and set the forwarder to be the virtual network's DNS resolver -- it should be the same as IP_ADDRESS_HERE, but ending in .1.
server# systemctl disable --now systemd-resolved.service
server# unlink /etc/resolv.conf
server# cat > /etc/resolv.conf << _EOF_
nameserver IP_ADDRESS_HERE
search test.lan
_EOF_
server# reboot
This should be enough to configure Samba as an AD DC. While at it, create a test user that will later be used to trigger the bug.
server# samba-tool user create testuser MyUserPassword1
== VM AD client setup ==
Let's configure a VM to act as an AD client.
$ lxc launch ubuntu-daily:jammy sssdclient -n virbr2 --vm
$ lxc shell sssdclient
client# apt update
client# apt install -y sssd-ad sssd-tools realmd adcli sssd-dbus
client# pam-auth-update --enable mkhomedir
We can now check if our container can detect the AD DC:
client# realm -v discover sambadc.test.lan
* Resolving: _ldap._tcp.sambadc.test.lan
* Resolving: sambadc.test.lan
* Performing LDAP DSE lookup on: 192.168.101.142
* Successfully discovered: test.lan
test.lan
type: kerberos
realm-name: TEST.LAN
domain-name: test.lan
configured: no
server-software: active-directory
client-software: sssd
required-package: sssd-tools
required-package: sssd
required-package: libnss-sss
required-package: libpam-sss
required-package: adcli
required-package: samba-common-bin
And we can join the realm:
client# realm -v join sambadc.test.lan
You will be prompted the password for the Administrator user. It is MyPassword1. If everything worked OK, you should now be able to list the information from the Administrator user:
client# getent passwd Administrator@TEST.LAN
administrator@test.lan:*:1522000500:1522000513:Administrator:/home/administrator@test.lan:/bin/bash
== Reproducing the bug ==
Make sure you can obtain the passwd information for the test user we've created in the Samba AD DC server.
client# getent passwd testuser@TEST.LAN
testuser@test.lan:*:1522001104:1522000513:testuser:/home/testuser@test.lan:/bin/bash
Now, try to login as the user:
client# login testuser@TEST.LAN
Password: MyUserPassword1
System error
As can be seen, the user will get a system error when trying to login in a default AD DC setup. In order to confirm that the problem is indeed caused by GPO, the following line can be added to the end of the /etc/sssd/sssd.conf file:
ad_gpo_access_control = permissive
After restarting sssd.service and trying to login again, you can confirm that it succeeds.
Be aware of the client-side caching when testing sssd. Sometimes the authentication can work when it's not expected to, or vice-versa. It's recommended to completely remove sssd's cache before testing a new scenario:
client# sssctl cache-remove -o -p -s
[ Where problems could occur ]
The behaviour being introduced by this change goes against the specificiation for Group Policies by Microsoft. It is worth mentioning that Microsoft Windows itself does *not* follow the specification either, so in a way we are bringing sssd to the "de facto" standard. But users can be surprised to see the authentication process successfully finish even if there is no SecEdit\GptTmpl.inf available.
As usual, there is also the small risk of rebuilding a package against newer dependencies in the archive.
[ Original Description ]
Hello,
After upgrade of sssd packages from version 2.2.3-3ubuntu0.4 to version 2.2.3-3ubuntu0.6, I could not authenticate with users from my Samba4 directory.
After enabling debug, I can see in /var/log/sssd/gpo_child.log errors:
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): gpo_child started.
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): context initialized
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x0400): cached_gpt_version: -1
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_server length: 21
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_server: smb://MY_SERVER_FQDN
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_share length: 7
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_share: /sysvol
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_path length: 60
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_path: /MY_DOMAIN/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_cse_suffix length: 49
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_cse_suffix: /Machine/Microsoft/Windows NT/SecEdit/GptTmpl.inf
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): performing smb operations
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [copy_smb_file_to_gpo_cache] (0x0400): smb_uri: smb://MY_SERVER_FQDN/sysvol/MY_DOMAIN/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}/GPT.INI
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [copy_smb_file_to_gpo_cache] (0x0020): smbc_getFunctionOpen failed [13][Permission denied]
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [perform_smb_operations] (0x0020): copy_smb_file_to_gpo_cache failed [13][Permission denied]
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0020): perform_smb_operations failed.[13][Permission denied].
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0020): gpo_child failed!
(I have replaced real server and domain name by MY_SERVER_FQDN and MY_DOMAIN)
As a workaround, I add new option 'ad_gpo_access_control = permissive' in sssd.conf and authentication is working again, but I'm wondering why upgrade has broken authentication, and what is the impact of the option ?
here is my sssd.conf:
[sssd]
default_domain_suffix = my_domain
full_name_format = %1$s
domains = my_domain
config_file_version = 2
services = nss, pam
[domain/my_domain]
debug_level=9
default_shell = /bin/bash
krb5_store_password_if_offline = True
cache_credentials = True
krb5_realm = MY_DOMAIN
realmd_tags = manages-system joined-with-adcli
id_provider = ad
fallback_homedir = /home/%d/%u
ad_domain = my_domain
use_fully_qualified_names = True
ldap_id_mapping = True
access_provider = ad
After adding 'ad_gpo_access_control = permissive' at the end of file, authentication with samba4 users works again.
Thanks! |
|
| 2022-06-21 17:47:58 |
Sergio Durigan Junior |
description |
[ Impact ]
A user running a Samba Active Directory Domain Controller compliant with the MS ADTS specifications in regards to how GPO is handled will experience authentication failures when joining an AD realm using the Ubuntu sssd package on Focal, Impish and Jammy with the "fix-gpo-MS-ADTS-compliance.patch" patch applied. Although there is a relatively simple workaround (setting "ad_gpo_access_control = permissive" in /etc/sssd/sssd.conf), we can and should support regular user authentication out of the box.
Upstream sssd has fixed this problem on version 2.7.0, which will be available in Kinetic soon.
[ Test Plan ]
The test case for this bug is a bit complex, but I will do my best to describe it in detail.
We need to setup one VM running a Samba Active Directory Domain Controller (AD DC), which will be our main server. This needs only to be configured once. We then need to setup another VM which will join our AD DC realm using realmd and sssd.
== Virtual Network setup ==
The first step is to create a dedicated virtual network for our tests. This is not strictly mandatory, but it will simplify things. The best way to create this network is via virt-manager. Install it if needed, open the program and select the "QEMU/KVM" line. Go to Edit > Connection Details > Virtual Networks, click on the "+" icon (bottom left), give this network a name (I will use "sssdad"), make sure that "Enable IPv4" and "Enable DHCPv4" are selected (under "IPv4 configuration"). Go to "DNS domain name" and select "Custom". For the domain name, type "test.lan". Click on "Finish".
Take note of the "Device" name that shows up after you create the network. We will use it when creating the VMs. For this test plan, let's assume the device name is "virbr1".
== Samba AD DC VM setup ==
We need to setup a Samba AD DC server. It doesn't matter which Ubuntu release we use for it. Note that we have to use "-n virbr1" when creating the VM, otherwise it won't use our virtual network.
$ lxc launch ubuntu-daily:jammy sambadc -n virbr1 --vm
$ lxc shell sambadc
server# apt update
server# ip a
Make sure to grab this VM's IP address.
server# cat >> /etc/hosts << _EOF_
IP_ADDRESS_HERE sambadc sambadc.test.lan
_EOF_
server# reboot
$ lxc shell sambadc
server# apt install -y samba winbind
server# mv /etc/samba/smb.conf /etc/samba/smb.conf.bkp
server# samba-tool domain provision --use-rfc2307 --realm TEST.LAN --domain TEST --server-role dc --dns-backend SAMBA_INTERNAL --adminpass MyPassword1
server# systemctl mask smbd.service nmbd.service winbind.service
server# systemctl disable --now smbd.service nmbd.service winbind.service
server# systemctl unmask samba-ad-dc.service
server# systemctl enable --now samba-ad-dc.service
We now have to adjust the DNS server settings of the server. We are going to disable systemd-resolved.service and use samba as our DNS service.
You will notice that the samba-tool command issued above has added 127.0.0.53 as the "dns forwarder" in /etc/samba/smb.conf. Edit the file and set the forwarder to be the virtual network's DNS resolver -- it should be the same as IP_ADDRESS_HERE, but ending in .1.
server# systemctl disable --now systemd-resolved.service
server# unlink /etc/resolv.conf
server# cat > /etc/resolv.conf << _EOF_
nameserver IP_ADDRESS_HERE
search test.lan
_EOF_
server# reboot
This should be enough to configure Samba as an AD DC. While at it, create a test user that will later be used to trigger the bug.
server# samba-tool user create testuser MyUserPassword1
== VM AD client setup ==
Let's configure a VM to act as an AD client.
$ lxc launch ubuntu-daily:jammy sssdclient -n virbr2 --vm
$ lxc shell sssdclient
client# apt update
client# apt install -y sssd-ad sssd-tools realmd adcli sssd-dbus
client# pam-auth-update --enable mkhomedir
We can now check if our container can detect the AD DC:
client# realm -v discover sambadc.test.lan
* Resolving: _ldap._tcp.sambadc.test.lan
* Resolving: sambadc.test.lan
* Performing LDAP DSE lookup on: 192.168.101.142
* Successfully discovered: test.lan
test.lan
type: kerberos
realm-name: TEST.LAN
domain-name: test.lan
configured: no
server-software: active-directory
client-software: sssd
required-package: sssd-tools
required-package: sssd
required-package: libnss-sss
required-package: libpam-sss
required-package: adcli
required-package: samba-common-bin
And we can join the realm:
client# realm -v join sambadc.test.lan
You will be prompted the password for the Administrator user. It is MyPassword1. If everything worked OK, you should now be able to list the information from the Administrator user:
client# getent passwd Administrator@TEST.LAN
administrator@test.lan:*:1522000500:1522000513:Administrator:/home/administrator@test.lan:/bin/bash
== Reproducing the bug ==
Make sure you can obtain the passwd information for the test user we've created in the Samba AD DC server.
client# getent passwd testuser@TEST.LAN
testuser@test.lan:*:1522001104:1522000513:testuser:/home/testuser@test.lan:/bin/bash
Now, try to login as the user:
client# login testuser@TEST.LAN
Password: MyUserPassword1
System error
As can be seen, the user will get a system error when trying to login in a default AD DC setup. In order to confirm that the problem is indeed caused by GPO, the following line can be added to the end of the /etc/sssd/sssd.conf file:
ad_gpo_access_control = permissive
After restarting sssd.service and trying to login again, you can confirm that it succeeds.
Be aware of the client-side caching when testing sssd. Sometimes the authentication can work when it's not expected to, or vice-versa. It's recommended to completely remove sssd's cache before testing a new scenario:
client# sssctl cache-remove -o -p -s
[ Where problems could occur ]
The behaviour being introduced by this change goes against the specificiation for Group Policies by Microsoft. It is worth mentioning that Microsoft Windows itself does *not* follow the specification either, so in a way we are bringing sssd to the "de facto" standard. But users can be surprised to see the authentication process successfully finish even if there is no SecEdit\GptTmpl.inf available.
As usual, there is also the small risk of rebuilding a package against newer dependencies in the archive.
[ Original Description ]
Hello,
After upgrade of sssd packages from version 2.2.3-3ubuntu0.4 to version 2.2.3-3ubuntu0.6, I could not authenticate with users from my Samba4 directory.
After enabling debug, I can see in /var/log/sssd/gpo_child.log errors:
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): gpo_child started.
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): context initialized
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x0400): cached_gpt_version: -1
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_server length: 21
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_server: smb://MY_SERVER_FQDN
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_share length: 7
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_share: /sysvol
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_path length: 60
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_path: /MY_DOMAIN/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_cse_suffix length: 49
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_cse_suffix: /Machine/Microsoft/Windows NT/SecEdit/GptTmpl.inf
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): performing smb operations
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [copy_smb_file_to_gpo_cache] (0x0400): smb_uri: smb://MY_SERVER_FQDN/sysvol/MY_DOMAIN/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}/GPT.INI
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [copy_smb_file_to_gpo_cache] (0x0020): smbc_getFunctionOpen failed [13][Permission denied]
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [perform_smb_operations] (0x0020): copy_smb_file_to_gpo_cache failed [13][Permission denied]
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0020): perform_smb_operations failed.[13][Permission denied].
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0020): gpo_child failed!
(I have replaced real server and domain name by MY_SERVER_FQDN and MY_DOMAIN)
As a workaround, I add new option 'ad_gpo_access_control = permissive' in sssd.conf and authentication is working again, but I'm wondering why upgrade has broken authentication, and what is the impact of the option ?
here is my sssd.conf:
[sssd]
default_domain_suffix = my_domain
full_name_format = %1$s
domains = my_domain
config_file_version = 2
services = nss, pam
[domain/my_domain]
debug_level=9
default_shell = /bin/bash
krb5_store_password_if_offline = True
cache_credentials = True
krb5_realm = MY_DOMAIN
realmd_tags = manages-system joined-with-adcli
id_provider = ad
fallback_homedir = /home/%d/%u
ad_domain = my_domain
use_fully_qualified_names = True
ldap_id_mapping = True
access_provider = ad
After adding 'ad_gpo_access_control = permissive' at the end of file, authentication with samba4 users works again.
Thanks! |
[ Impact ]
A user running a Samba Active Directory Domain Controller compliant with the MS ADTS specifications in regards to how GPO is handled will experience authentication failures when joining an AD realm using the Ubuntu sssd package on Focal, Impish and Jammy with the "fix-gpo-MS-ADTS-compliance.patch" patch applied. Although there is a relatively simple workaround (setting "ad_gpo_access_control = permissive" in /etc/sssd/sssd.conf), we can and should support regular user authentication out of the box.
Upstream sssd has fixed this problem on version 2.7.0, which will be available in Kinetic soon.
[ Test Plan ]
The test case for this bug is a bit complex, but I will do my best to describe it in detail.
We need to setup one VM running a Samba Active Directory Domain Controller (AD DC), which will be our main server. This needs only to be configured once. We then need to setup another VM which will join our AD DC realm using realmd and sssd.
== Virtual Network setup ==
The first step is to create a dedicated virtual network for our tests. This is not strictly mandatory, but it will simplify things. The best way to create this network is via virt-manager. Install it if needed, open the program and select the "QEMU/KVM" line. Go to Edit > Connection Details > Virtual Networks, click on the "+" icon (bottom left), give this network a name (I will use "sssdad"), make sure that "Enable IPv4" and "Enable DHCPv4" are selected (under "IPv4 configuration"). Go to "DNS domain name" and select "Custom". For the domain name, type "test.lan". Click on "Finish".
Take note of the "Device" name that shows up after you create the network. We will use it when creating the VMs. For this test plan, let's assume the device name is "virbr1".
== Samba AD DC VM setup ==
We need to setup a Samba AD DC server. It doesn't matter which Ubuntu release we use for it. Note that we have to use "-n virbr1" when creating the VM, otherwise it won't use our virtual network.
$ lxc launch ubuntu-daily:jammy sambadc -n virbr1 --vm
$ lxc shell sambadc
server# apt update
server# ip a
Make sure to grab this VM's IP address.
server# cat >> /etc/hosts << _EOF_
IP_ADDRESS_HERE sambadc sambadc.test.lan
_EOF_
server# reboot
$ lxc shell sambadc
server# apt install -y samba winbind
server# mv /etc/samba/smb.conf /etc/samba/smb.conf.bkp
server# samba-tool domain provision --use-rfc2307 --realm TEST.LAN --domain TEST --server-role dc --dns-backend SAMBA_INTERNAL --adminpass MyPassword1
server# systemctl mask smbd.service nmbd.service winbind.service
server# systemctl disable --now smbd.service nmbd.service winbind.service
server# systemctl unmask samba-ad-dc.service
server# systemctl enable --now samba-ad-dc.service
We now have to adjust the DNS server settings of the server. We are going to disable systemd-resolved.service and use samba as our DNS service.
You will notice that the samba-tool command issued above has added 127.0.0.53 as the "dns forwarder" in /etc/samba/smb.conf. Edit the file and set the forwarder to be the virtual network's DNS resolver -- it should be the same as IP_ADDRESS_HERE, but ending in .1.
server# systemctl disable --now systemd-resolved.service
server# unlink /etc/resolv.conf
server# cat > /etc/resolv.conf << _EOF_
nameserver IP_ADDRESS_HERE
search test.lan
_EOF_
server# reboot
This should be enough to configure Samba as an AD DC. While at it, create a test user that will later be used to trigger the bug.
server# samba-tool user create testuser MyUserPassword1
== VM AD client setup ==
Let's configure a VM to act as an AD client.
$ lxc launch ubuntu-daily:jammy sssdclient -n virbr2 --vm
$ lxc shell sssdclient
Before anything else, let's configure this VM to use the Samba AD DC VM as its DNS resolver. In the excerpt below, IP_ADDRESS_HERE refers to the IP address of the Samba AD DC VM (configured in the last section).
client# systemctl disable --now systemd-resolved.service
client# unlink /etc/resolv.conf
client# cat > /etc/resolv.conf << _EOF_
nameserver IP_ADDRESS_HERE
search test.lan
_EOF_
client# apt update
client# apt install -y sssd-ad sssd-tools realmd adcli sssd-dbus
client# pam-auth-update --enable mkhomedir
We can now check if our container can detect the AD DC:
client# realm -v discover sambadc.test.lan
* Resolving: _ldap._tcp.sambadc.test.lan
* Resolving: sambadc.test.lan
* Performing LDAP DSE lookup on: 192.168.101.142
* Successfully discovered: test.lan
test.lan
type: kerberos
realm-name: TEST.LAN
domain-name: test.lan
configured: no
server-software: active-directory
client-software: sssd
required-package: sssd-tools
required-package: sssd
required-package: libnss-sss
required-package: libpam-sss
required-package: adcli
required-package: samba-common-bin
You can also confirm that the "realm -v discover" works on the domain name:
client# realm -v discover test.lan
* Resolving: _ldap._tcp.test.lan
* Performing LDAP DSE lookup on: 192.168.101.142
* Successfully discovered: test.lan
test.lan
type: kerberos
realm-name: TEST.LAN
domain-name: test.lan
configured: no
server-software: active-directory
client-software: sssd
required-package: sssd-tools
required-package: sssd
required-package: libnss-sss
required-package: libpam-sss
required-package: adcli
required-package: samba-common-bin
And we can join the realm:
client# realm -v join test.lan
You will be prompted the password for the Administrator user. It is MyPassword1. If everything worked OK, you should now be able to list the information from the Administrator user:
client# getent passwd Administrator@TEST.LAN
administrator@test.lan:*:1522000500:1522000513:Administrator:/home/administrator@test.lan:/bin/bash
== Reproducing the bug ==
Make sure you can obtain the passwd information for the test user we've created in the Samba AD DC server.
client# getent passwd testuser@TEST.LAN
testuser@test.lan:*:1522001104:1522000513:testuser:/home/testuser@test.lan:/bin/bash
Now, try to login as the user:
client# login testuser@TEST.LAN
Password: MyUserPassword1
System error
As can be seen, the user will get a system error when trying to login in a default AD DC setup. In order to confirm that the problem is indeed caused by GPO, the following line can be added to the end of the /etc/sssd/sssd.conf file:
ad_gpo_access_control = permissive
After restarting sssd.service and trying to login again, you can confirm that it succeeds.
Be aware of the client-side caching when testing sssd. Sometimes the authentication can work when it's not expected to, or vice-versa. It's recommended to completely remove sssd's cache before testing a new scenario:
client# sssctl cache-remove -o -p -s
[ Where problems could occur ]
The behaviour being introduced by this change goes against the specificiation for Group Policies by Microsoft. It is worth mentioning that Microsoft Windows itself does *not* follow the specification either, so in a way we are bringing sssd to the "de facto" standard. But users can be surprised to see the authentication process successfully finish even if there is no SecEdit\GptTmpl.inf available.
As usual, there is also the small risk of rebuilding a package against newer dependencies in the archive.
[ Original Description ]
Hello,
After upgrade of sssd packages from version 2.2.3-3ubuntu0.4 to version 2.2.3-3ubuntu0.6, I could not authenticate with users from my Samba4 directory.
After enabling debug, I can see in /var/log/sssd/gpo_child.log errors:
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): gpo_child started.
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): context initialized
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x0400): cached_gpt_version: -1
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_server length: 21
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_server: smb://MY_SERVER_FQDN
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_share length: 7
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_share: /sysvol
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_path length: 60
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_path: /MY_DOMAIN/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_cse_suffix length: 49
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_cse_suffix: /Machine/Microsoft/Windows NT/SecEdit/GptTmpl.inf
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): performing smb operations
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [copy_smb_file_to_gpo_cache] (0x0400): smb_uri: smb://MY_SERVER_FQDN/sysvol/MY_DOMAIN/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}/GPT.INI
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [copy_smb_file_to_gpo_cache] (0x0020): smbc_getFunctionOpen failed [13][Permission denied]
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [perform_smb_operations] (0x0020): copy_smb_file_to_gpo_cache failed [13][Permission denied]
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0020): perform_smb_operations failed.[13][Permission denied].
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0020): gpo_child failed!
(I have replaced real server and domain name by MY_SERVER_FQDN and MY_DOMAIN)
As a workaround, I add new option 'ad_gpo_access_control = permissive' in sssd.conf and authentication is working again, but I'm wondering why upgrade has broken authentication, and what is the impact of the option ?
here is my sssd.conf:
[sssd]
default_domain_suffix = my_domain
full_name_format = %1$s
domains = my_domain
config_file_version = 2
services = nss, pam
[domain/my_domain]
debug_level=9
default_shell = /bin/bash
krb5_store_password_if_offline = True
cache_credentials = True
krb5_realm = MY_DOMAIN
realmd_tags = manages-system joined-with-adcli
id_provider = ad
fallback_homedir = /home/%d/%u
ad_domain = my_domain
use_fully_qualified_names = True
ldap_id_mapping = True
access_provider = ad
After adding 'ad_gpo_access_control = permissive' at the end of file, authentication with samba4 users works again.
Thanks! |
|
| 2022-06-21 17:58:14 |
Sergio Durigan Junior |
description |
[ Impact ]
A user running a Samba Active Directory Domain Controller compliant with the MS ADTS specifications in regards to how GPO is handled will experience authentication failures when joining an AD realm using the Ubuntu sssd package on Focal, Impish and Jammy with the "fix-gpo-MS-ADTS-compliance.patch" patch applied. Although there is a relatively simple workaround (setting "ad_gpo_access_control = permissive" in /etc/sssd/sssd.conf), we can and should support regular user authentication out of the box.
Upstream sssd has fixed this problem on version 2.7.0, which will be available in Kinetic soon.
[ Test Plan ]
The test case for this bug is a bit complex, but I will do my best to describe it in detail.
We need to setup one VM running a Samba Active Directory Domain Controller (AD DC), which will be our main server. This needs only to be configured once. We then need to setup another VM which will join our AD DC realm using realmd and sssd.
== Virtual Network setup ==
The first step is to create a dedicated virtual network for our tests. This is not strictly mandatory, but it will simplify things. The best way to create this network is via virt-manager. Install it if needed, open the program and select the "QEMU/KVM" line. Go to Edit > Connection Details > Virtual Networks, click on the "+" icon (bottom left), give this network a name (I will use "sssdad"), make sure that "Enable IPv4" and "Enable DHCPv4" are selected (under "IPv4 configuration"). Go to "DNS domain name" and select "Custom". For the domain name, type "test.lan". Click on "Finish".
Take note of the "Device" name that shows up after you create the network. We will use it when creating the VMs. For this test plan, let's assume the device name is "virbr1".
== Samba AD DC VM setup ==
We need to setup a Samba AD DC server. It doesn't matter which Ubuntu release we use for it. Note that we have to use "-n virbr1" when creating the VM, otherwise it won't use our virtual network.
$ lxc launch ubuntu-daily:jammy sambadc -n virbr1 --vm
$ lxc shell sambadc
server# apt update
server# ip a
Make sure to grab this VM's IP address.
server# cat >> /etc/hosts << _EOF_
IP_ADDRESS_HERE sambadc sambadc.test.lan
_EOF_
server# reboot
$ lxc shell sambadc
server# apt install -y samba winbind
server# mv /etc/samba/smb.conf /etc/samba/smb.conf.bkp
server# samba-tool domain provision --use-rfc2307 --realm TEST.LAN --domain TEST --server-role dc --dns-backend SAMBA_INTERNAL --adminpass MyPassword1
server# systemctl mask smbd.service nmbd.service winbind.service
server# systemctl disable --now smbd.service nmbd.service winbind.service
server# systemctl unmask samba-ad-dc.service
server# systemctl enable --now samba-ad-dc.service
We now have to adjust the DNS server settings of the server. We are going to disable systemd-resolved.service and use samba as our DNS service.
You will notice that the samba-tool command issued above has added 127.0.0.53 as the "dns forwarder" in /etc/samba/smb.conf. Edit the file and set the forwarder to be the virtual network's DNS resolver -- it should be the same as IP_ADDRESS_HERE, but ending in .1.
server# systemctl disable --now systemd-resolved.service
server# unlink /etc/resolv.conf
server# cat > /etc/resolv.conf << _EOF_
nameserver IP_ADDRESS_HERE
search test.lan
_EOF_
server# reboot
This should be enough to configure Samba as an AD DC. While at it, create a test user that will later be used to trigger the bug.
server# samba-tool user create testuser MyUserPassword1
== VM AD client setup ==
Let's configure a VM to act as an AD client.
$ lxc launch ubuntu-daily:jammy sssdclient -n virbr2 --vm
$ lxc shell sssdclient
Before anything else, let's configure this VM to use the Samba AD DC VM as its DNS resolver. In the excerpt below, IP_ADDRESS_HERE refers to the IP address of the Samba AD DC VM (configured in the last section).
client# systemctl disable --now systemd-resolved.service
client# unlink /etc/resolv.conf
client# cat > /etc/resolv.conf << _EOF_
nameserver IP_ADDRESS_HERE
search test.lan
_EOF_
client# apt update
client# apt install -y sssd-ad sssd-tools realmd adcli sssd-dbus
client# pam-auth-update --enable mkhomedir
We can now check if our container can detect the AD DC:
client# realm -v discover sambadc.test.lan
* Resolving: _ldap._tcp.sambadc.test.lan
* Resolving: sambadc.test.lan
* Performing LDAP DSE lookup on: 192.168.101.142
* Successfully discovered: test.lan
test.lan
type: kerberos
realm-name: TEST.LAN
domain-name: test.lan
configured: no
server-software: active-directory
client-software: sssd
required-package: sssd-tools
required-package: sssd
required-package: libnss-sss
required-package: libpam-sss
required-package: adcli
required-package: samba-common-bin
You can also confirm that the "realm -v discover" works on the domain name:
client# realm -v discover test.lan
* Resolving: _ldap._tcp.test.lan
* Performing LDAP DSE lookup on: 192.168.101.142
* Successfully discovered: test.lan
test.lan
type: kerberos
realm-name: TEST.LAN
domain-name: test.lan
configured: no
server-software: active-directory
client-software: sssd
required-package: sssd-tools
required-package: sssd
required-package: libnss-sss
required-package: libpam-sss
required-package: adcli
required-package: samba-common-bin
And we can join the realm:
client# realm -v join test.lan
You will be prompted the password for the Administrator user. It is MyPassword1. If everything worked OK, you should now be able to list the information from the Administrator user:
client# getent passwd Administrator@TEST.LAN
administrator@test.lan:*:1522000500:1522000513:Administrator:/home/administrator@test.lan:/bin/bash
== Reproducing the bug ==
Make sure you can obtain the passwd information for the test user we've created in the Samba AD DC server.
client# getent passwd testuser@TEST.LAN
testuser@test.lan:*:1522001104:1522000513:testuser:/home/testuser@test.lan:/bin/bash
Now, try to login as the user:
client# login testuser@TEST.LAN
Password: MyUserPassword1
System error
As can be seen, the user will get a system error when trying to login in a default AD DC setup. In order to confirm that the problem is indeed caused by GPO, the following line can be added to the end of the /etc/sssd/sssd.conf file:
ad_gpo_access_control = permissive
After restarting sssd.service and trying to login again, you can confirm that it succeeds.
Be aware of the client-side caching when testing sssd. Sometimes the authentication can work when it's not expected to, or vice-versa. It's recommended to completely remove sssd's cache before testing a new scenario:
client# sssctl cache-remove -o -p -s
[ Where problems could occur ]
The behaviour being introduced by this change goes against the specificiation for Group Policies by Microsoft. It is worth mentioning that Microsoft Windows itself does *not* follow the specification either, so in a way we are bringing sssd to the "de facto" standard. But users can be surprised to see the authentication process successfully finish even if there is no SecEdit\GptTmpl.inf available.
As usual, there is also the small risk of rebuilding a package against newer dependencies in the archive.
[ Original Description ]
Hello,
After upgrade of sssd packages from version 2.2.3-3ubuntu0.4 to version 2.2.3-3ubuntu0.6, I could not authenticate with users from my Samba4 directory.
After enabling debug, I can see in /var/log/sssd/gpo_child.log errors:
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): gpo_child started.
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): context initialized
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x0400): cached_gpt_version: -1
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_server length: 21
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_server: smb://MY_SERVER_FQDN
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_share length: 7
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_share: /sysvol
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_path length: 60
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_path: /MY_DOMAIN/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_cse_suffix length: 49
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_cse_suffix: /Machine/Microsoft/Windows NT/SecEdit/GptTmpl.inf
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): performing smb operations
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [copy_smb_file_to_gpo_cache] (0x0400): smb_uri: smb://MY_SERVER_FQDN/sysvol/MY_DOMAIN/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}/GPT.INI
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [copy_smb_file_to_gpo_cache] (0x0020): smbc_getFunctionOpen failed [13][Permission denied]
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [perform_smb_operations] (0x0020): copy_smb_file_to_gpo_cache failed [13][Permission denied]
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0020): perform_smb_operations failed.[13][Permission denied].
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0020): gpo_child failed!
(I have replaced real server and domain name by MY_SERVER_FQDN and MY_DOMAIN)
As a workaround, I add new option 'ad_gpo_access_control = permissive' in sssd.conf and authentication is working again, but I'm wondering why upgrade has broken authentication, and what is the impact of the option ?
here is my sssd.conf:
[sssd]
default_domain_suffix = my_domain
full_name_format = %1$s
domains = my_domain
config_file_version = 2
services = nss, pam
[domain/my_domain]
debug_level=9
default_shell = /bin/bash
krb5_store_password_if_offline = True
cache_credentials = True
krb5_realm = MY_DOMAIN
realmd_tags = manages-system joined-with-adcli
id_provider = ad
fallback_homedir = /home/%d/%u
ad_domain = my_domain
use_fully_qualified_names = True
ldap_id_mapping = True
access_provider = ad
After adding 'ad_gpo_access_control = permissive' at the end of file, authentication with samba4 users works again.
Thanks! |
[ Impact ]
A user running a Samba Active Directory Domain Controller compliant with the MS ADTS specifications in regards to how GPO is handled will experience authentication failures when joining an AD realm using the Ubuntu sssd package on Focal, Impish and Jammy with the "fix-gpo-MS-ADTS-compliance.patch" patch applied. Although there is a relatively simple workaround (setting "ad_gpo_access_control = permissive" in /etc/sssd/sssd.conf), we can and should support regular user authentication out of the box.
Upstream sssd has fixed this problem on version 2.7.0, which will be available in Kinetic soon.
[ Test Plan ]
The test case for this bug is a bit complex, but I will do my best to describe it in detail.
We need to setup one VM running a Samba Active Directory Domain Controller (AD DC), which will be our main server. This needs only to be configured once. We then need to setup another VM which will join our AD DC realm using realmd and sssd.
== Virtual Network setup ==
The first step is to create a dedicated virtual network for our tests. This is not strictly mandatory, but it will simplify things. The best way to create this network is via virt-manager. Install it if needed, open the program and select the "QEMU/KVM" line. Go to Edit > Connection Details > Virtual Networks, click on the "+" icon (bottom left), give this network a name (I will use "sssdad"), make sure that "Enable IPv4" and "Enable DHCPv4" are selected (under "IPv4 configuration"). Go to "DNS domain name" and select "Custom". For the domain name, type "test.lan". Click on "Finish".
Take note of the "Device" name that shows up after you create the network. We will use it when creating the VMs. For this test plan, let's assume the device name is "virbr1".
== Samba AD DC VM setup ==
We need to setup a Samba AD DC server. It doesn't matter which Ubuntu release we use for it. Note that we have to use "-n virbr1" when creating the VM, otherwise it won't use our virtual network.
$ lxc launch ubuntu-daily:jammy sambadc -n virbr1 --vm
$ lxc shell sambadc
server# apt update
server# ip a
Make sure to grab this VM's IP address.
server# cat >> /etc/hosts << _EOF_
IP_ADDRESS_HERE sambadc sambadc.test.lan
_EOF_
server# reboot
$ lxc shell sambadc
server# apt install -y samba winbind
server# mv /etc/samba/smb.conf /etc/samba/smb.conf.bkp
server# samba-tool domain provision --use-rfc2307 --realm TEST.LAN --domain TEST --server-role dc --dns-backend SAMBA_INTERNAL --adminpass MyPassword1
server# systemctl mask smbd.service nmbd.service winbind.service
server# systemctl disable --now smbd.service nmbd.service winbind.service
server# systemctl unmask samba-ad-dc.service
server# systemctl enable --now samba-ad-dc.service
We now have to adjust the DNS server settings of the server. We are going to disable systemd-resolved.service and use samba as our DNS service.
You will notice that the samba-tool command issued above has added 127.0.0.53 as the "dns forwarder" in /etc/samba/smb.conf. Edit the file and set the forwarder to be the virtual network's DNS resolver -- it should be the same as IP_ADDRESS_HERE, but ending in .1.
server# systemctl disable --now systemd-resolved.service
server# unlink /etc/resolv.conf
server# cat > /etc/resolv.conf << _EOF_
nameserver IP_ADDRESS_HERE
search test.lan
_EOF_
server# reboot
This should be enough to configure Samba as an AD DC. While at it, create a test user that will later be used to trigger the bug.
server# samba-tool user create testuser MyUserPassword1
== VM AD client setup ==
Let's configure a VM to act as an AD client.
$ lxc launch ubuntu-daily:jammy sssdclient -n virbr1 --vm
$ lxc shell sssdclient
Before anything else, let's configure this VM to use the Samba AD DC VM as its DNS resolver. In the excerpt below, IP_ADDRESS_HERE refers to the IP address of the Samba AD DC VM (configured in the last section).
client# systemctl disable --now systemd-resolved.service
client# unlink /etc/resolv.conf
client# cat > /etc/resolv.conf << _EOF_
nameserver IP_ADDRESS_HERE
search test.lan
_EOF_
client# apt update
client# apt install -y sssd-ad sssd-tools realmd adcli sssd-dbus
client# pam-auth-update --enable mkhomedir
We can now check if our container can detect the AD DC:
client# realm -v discover sambadc.test.lan
* Resolving: _ldap._tcp.sambadc.test.lan
* Resolving: sambadc.test.lan
* Performing LDAP DSE lookup on: 192.168.101.142
* Successfully discovered: test.lan
test.lan
type: kerberos
realm-name: TEST.LAN
domain-name: test.lan
configured: no
server-software: active-directory
client-software: sssd
required-package: sssd-tools
required-package: sssd
required-package: libnss-sss
required-package: libpam-sss
required-package: adcli
required-package: samba-common-bin
You can also confirm that the "realm -v discover" works on the domain name:
client# realm -v discover test.lan
* Resolving: _ldap._tcp.test.lan
* Performing LDAP DSE lookup on: 192.168.101.142
* Successfully discovered: test.lan
test.lan
type: kerberos
realm-name: TEST.LAN
domain-name: test.lan
configured: no
server-software: active-directory
client-software: sssd
required-package: sssd-tools
required-package: sssd
required-package: libnss-sss
required-package: libpam-sss
required-package: adcli
required-package: samba-common-bin
And we can join the realm:
client# realm -v join test.lan
You will be prompted the password for the Administrator user. It is MyPassword1. If everything worked OK, you should now be able to list the information from the Administrator user:
client# getent passwd Administrator@TEST.LAN
administrator@test.lan:*:1522000500:1522000513:Administrator:/home/administrator@test.lan:/bin/bash
== Reproducing the bug ==
Make sure you can obtain the passwd information for the test user we've created in the Samba AD DC server.
client# getent passwd testuser@TEST.LAN
testuser@test.lan:*:1522001104:1522000513:testuser:/home/testuser@test.lan:/bin/bash
Now, try to login as the user:
client# login testuser@TEST.LAN
Password: MyUserPassword1
System error
As can be seen, the user will get a system error when trying to login in a default AD DC setup. In order to confirm that the problem is indeed caused by GPO, the following line can be added to the end of the /etc/sssd/sssd.conf file:
ad_gpo_access_control = permissive
After restarting sssd.service and trying to login again, you can confirm that it succeeds.
Be aware of the client-side caching when testing sssd. Sometimes the authentication can work when it's not expected to, or vice-versa. It's recommended to completely remove sssd's cache before testing a new scenario:
client# sssctl cache-remove -o -p -s
[ Where problems could occur ]
The behaviour being introduced by this change goes against the specificiation for Group Policies by Microsoft. It is worth mentioning that Microsoft Windows itself does *not* follow the specification either, so in a way we are bringing sssd to the "de facto" standard. But users can be surprised to see the authentication process successfully finish even if there is no SecEdit\GptTmpl.inf available.
As usual, there is also the small risk of rebuilding a package against newer dependencies in the archive.
[ Original Description ]
Hello,
After upgrade of sssd packages from version 2.2.3-3ubuntu0.4 to version 2.2.3-3ubuntu0.6, I could not authenticate with users from my Samba4 directory.
After enabling debug, I can see in /var/log/sssd/gpo_child.log errors:
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): gpo_child started.
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): context initialized
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x0400): cached_gpt_version: -1
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_server length: 21
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_server: smb://MY_SERVER_FQDN
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_share length: 7
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_share: /sysvol
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_path length: 60
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_path: /MY_DOMAIN/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_cse_suffix length: 49
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_cse_suffix: /Machine/Microsoft/Windows NT/SecEdit/GptTmpl.inf
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): performing smb operations
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [copy_smb_file_to_gpo_cache] (0x0400): smb_uri: smb://MY_SERVER_FQDN/sysvol/MY_DOMAIN/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}/GPT.INI
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [copy_smb_file_to_gpo_cache] (0x0020): smbc_getFunctionOpen failed [13][Permission denied]
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [perform_smb_operations] (0x0020): copy_smb_file_to_gpo_cache failed [13][Permission denied]
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0020): perform_smb_operations failed.[13][Permission denied].
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0020): gpo_child failed!
(I have replaced real server and domain name by MY_SERVER_FQDN and MY_DOMAIN)
As a workaround, I add new option 'ad_gpo_access_control = permissive' in sssd.conf and authentication is working again, but I'm wondering why upgrade has broken authentication, and what is the impact of the option ?
here is my sssd.conf:
[sssd]
default_domain_suffix = my_domain
full_name_format = %1$s
domains = my_domain
config_file_version = 2
services = nss, pam
[domain/my_domain]
debug_level=9
default_shell = /bin/bash
krb5_store_password_if_offline = True
cache_credentials = True
krb5_realm = MY_DOMAIN
realmd_tags = manages-system joined-with-adcli
id_provider = ad
fallback_homedir = /home/%d/%u
ad_domain = my_domain
use_fully_qualified_names = True
ldap_id_mapping = True
access_provider = ad
After adding 'ad_gpo_access_control = permissive' at the end of file, authentication with samba4 users works again.
Thanks! |
|
| 2022-06-22 14:47:09 |
Launchpad Janitor |
sssd (Ubuntu Kinetic): status |
Triaged |
Fix Released |
|
| 2022-06-27 21:36:50 |
Andreas Hasenack |
bug |
|
|
added subscriber Andreas Hasenack |
| 2022-07-01 20:20:34 |
Steve Langasek |
sssd (Ubuntu Jammy): status |
In Progress |
Fix Committed |
|
| 2022-07-01 20:20:37 |
Steve Langasek |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2022-07-01 20:20:39 |
Steve Langasek |
bug |
|
|
added subscriber SRU Verification |
| 2022-07-01 20:20:45 |
Steve Langasek |
tags |
regression-update server-todo |
regression-update server-todo verification-needed verification-needed-jammy |
|
| 2022-07-02 00:29:59 |
Andreas Hasenack |
tags |
regression-update server-todo verification-needed verification-needed-jammy |
regression-update server-todo verification-jammy-jammy verification-needed |
|
| 2022-07-02 00:39:16 |
Marcos Alano |
tags |
regression-update server-todo verification-jammy-jammy verification-needed |
regression-update server-todo verification-done-jammy verification-needed |
|
| 2022-07-06 06:31:10 |
Chris Halse Rogers |
sssd (Ubuntu Focal): status |
In Progress |
Fix Committed |
|
| 2022-07-06 06:31:26 |
Chris Halse Rogers |
tags |
regression-update server-todo verification-done-jammy verification-needed |
regression-update server-todo verification-done-jammy verification-needed verification-needed-focal |
|
| 2022-07-06 14:15:12 |
Andreas Hasenack |
tags |
regression-update server-todo verification-done-jammy verification-needed verification-needed-focal |
regression-update server-todo verification-done-focal verification-done-jammy verification-needed |
|
| 2022-07-12 23:17:46 |
Launchpad Janitor |
sssd (Ubuntu Jammy): status |
Fix Committed |
Fix Released |
|
| 2022-07-12 23:18:10 |
Brian Murray |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2022-07-13 15:06:13 |
Sergio Durigan Junior |
tags |
regression-update server-todo verification-done-focal verification-done-jammy verification-needed |
regression-update server-todo verification-done verification-done-focal verification-done-jammy |
|
| 2022-08-03 04:16:33 |
Launchpad Janitor |
sssd (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
| 2022-10-19 16:51:39 |
Michał Małoszewski |
tags |
regression-update server-todo verification-done verification-done-focal verification-done-jammy |
regression-update verification-done verification-done-focal verification-done-jammy |
|
| 2024-04-26 13:43:59 |
Raydel Govea |
bug |
|
|
added subscriber Raydel Govea |
