Adsys can't feth GPOs #733
Comments
|
After enabling log level 10 on smb.conf I'm getting this info: adsysctl update username@domain.com.br /tmp/krb5cc_1766406888_c2PVrz -vvvv I've added a adsys.yaml file with the default parameters just to get rid of that line in the beginning. adsys.yaml verbose: 2 service_timeout: 3600 |
|
Hey @JuarezPrates, thanks for reporting the issue! On Kinetic (22.10) and Lunar (23.04), there was a massive samba update that changed a bit of how things used to work with the Kerberos backend and this resulted in some bad things happening. Those are fixed now, but we didn't SRU the changes to those releases yet. On Jammy (22.04), this problem does not exist so I'll focus on it with you if that's alright...
It seems as though your policy directory does not have any |
|
Hi. Yes, the GPT.INI is present and uppercase in the domain controller. |
|
We are seeing the same issue in our environment as well and I have not been able to resolve or find much information on this. |
|
I have the same issue in my environment. I'm actively trying to find a work around. Anyone have any luck with this? |
|
I don't have time to test it in a lab enviroment with a brand new Active Directory Server, but I think it's the only thing I haven't checked yet. |
|
I can do a cifs mount to the GPT.INI file like you can and open it just fine but Adsys and Smbclient will fail out trying to hit those directly. I did notice smbclient works when using the -D flag....smbclient //example.com/sysvol -D "example.com/policies/{policy}" Without that flag (smbclient //example.com/sysvol/example.com/policies/{policy}) it comes back with tree connect failed: NT_STATUS_BAD_NETWORK_NAME Case matching doesn't seem to make a difference for me. I thought it was a client side configuration problem and have been tinkering with SMB.conf but I had not gotten anywhere. |
|
I think the problem might be in one of this files: adsys-gpolist or adsys-gpolist_test.go. I was grepping for NT_STATUS_BAD_NETWORK_NAME or NT_STATUS_INVALID_PARAMETER and found nothing, execpt for these two. |
|
I don't have a way to rule this out unfortunately. We do not have an assets (Ubuntu) folder that is being referenced here. I am not sure if because of that, Adsys totally craps out. I can use smbget and pull gpt.ini files without any issues as well.
|
This is the main driver for the changes in the previous commits. The way this behavior worked in the past is that we would use the URL returned in the gPCFileSysPath field without any changes. This introduced an inconsistency that went unobserved until recently. Namely, we would get the list of GPOs using the FQDN of the domain controller (e.g. adc.example.com), whereas the list of GPO URLs only included the domain name (e.g. example.com). This meant that when downloading the actual GPO data, libsmbclient would try to autodiscover a domain controller from which to perform the download, given only the domain name. In some cases, especially complicated AD deployments with lots of DCs, libsmbclient could autoresolve to an unhealthy DC (we take unhealthy to mean any DC from which GPO files cannot be downloaded, regardless of reason). This would fail the GPO download with a cryptic "invalid argument" error. Besides the chance of the above happening, autodiscovery also takes longer as opposed to passing a valid DC FQDN to libsmbclient from the start. To fix this, we rewrite the GPO URL in the gPCFileSysPath field to include the FQDN of the domain controller which essentially ensures the DC we get the GPO list from, and the DC we download the GPO data from are the same, minimizing the chance of mismatches like this occurring. This has some drawbacks in the integration tests where we set up a real SMB share and download from it, so we need to ensure the mocked server URL is the actual SMB server. Fixes #733 / UDENG-843
This is the main driver for the changes in the previous commits. The way this behavior worked in the past is that we would use the URL returned in the gPCFileSysPath field without any changes. This introduced an inconsistency that went unobserved until recently. Namely, we would get the list of GPOs using the FQDN of the domain controller (e.g. adc.example.com), whereas the list of GPO URLs only included the domain name (e.g. example.com). This meant that when downloading the actual GPO data, libsmbclient would try to autodiscover a domain controller from which to perform the download, given only the domain name. In some cases, especially complicated AD deployments with lots of DCs, libsmbclient could autoresolve to an unhealthy DC (we take unhealthy to mean any DC from which GPO files cannot be downloaded, regardless of reason). This would fail the GPO download with a cryptic "invalid argument" error. Besides the chance of the above happening, autodiscovery also takes longer as opposed to passing a valid DC FQDN to libsmbclient from the start. To fix this, we rewrite the GPO URL in the gPCFileSysPath field to include the FQDN of the domain controller which essentially ensures the DC we get the GPO list from, and the DC we download the GPO data from are the same, minimizing the chance of mismatches like this occurring. This has some drawbacks in the integration tests where we set up a real SMB share and download from it, so we need to ensure the mocked server URL is the actual SMB server. Fixes #733 / UDENG-843
This is the main driver for the changes in the previous commits. The way this behavior worked in the past is that we would use the URL returned in the gPCFileSysPath field without any changes. This introduced an inconsistency that went unobserved until recently. Namely, we would get the list of GPOs using the FQDN of the domain controller (e.g. adc.example.com), whereas the list of GPO URLs only included the domain name (e.g. example.com). This meant that when downloading the actual GPO data, libsmbclient would try to autodiscover a domain controller from which to perform the download, given only the domain name. In some cases, especially complicated AD deployments with lots of DCs, libsmbclient could autoresolve to an unhealthy DC (we take unhealthy to mean any DC from which GPO files cannot be downloaded, regardless of reason). This would fail the GPO download with a cryptic "invalid argument" error. Besides the chance of the above happening, autodiscovery also takes longer as opposed to passing a valid DC FQDN to libsmbclient from the start. To fix this, we rewrite the GPO URL in the gPCFileSysPath field to include the FQDN of the domain controller which essentially ensures the DC we get the GPO list from, and the DC we download the GPO data from are the same, minimizing the chance of mismatches like this occurring. This has some drawbacks in the integration tests where we set up a real SMB share and download from it, so we need to ensure the mocked server URL is the actual SMB server. Fixes #733 / UDENG-843
This is the main driver for the changes in the previous commits. The way this behavior worked in the past is that we would use the URL returned in the gPCFileSysPath field without any changes. This introduced an inconsistency that went unobserved until recently. Namely, we would get the list of GPOs using the FQDN of the domain controller (e.g. adc.example.com), whereas the list of GPO URLs only included the domain name (e.g. example.com). This meant that when downloading the actual GPO data, libsmbclient would try to autodiscover a domain controller from which to perform the download, given only the domain name. In some cases, especially complicated AD deployments with lots of DCs, libsmbclient could autoresolve to an unhealthy DC (we take unhealthy to mean any DC from which GPO files cannot be downloaded, regardless of reason). This would fail the GPO download with a cryptic "invalid argument" error. Besides the chance of the above happening, autodiscovery also takes longer as opposed to passing a valid DC FQDN to libsmbclient from the start. To fix this, we rewrite the GPO URL in the gPCFileSysPath field to include the FQDN of the domain controller which essentially ensures the DC we get the GPO list from, and the DC we download the GPO data from are the same, minimizing the chance of mismatches like this occurring. This has some drawbacks in the integration tests where we set up a real SMB share and download from it, so we need to ensure the mocked server URL is the actual SMB server. Fixes #733 / UDENG-843
This is the main driver for the changes in the previous commits. The way this behavior worked in the past is that we would use the URL returned in the gPCFileSysPath field without any changes. This introduced an inconsistency that went unobserved until recently. Namely, we would get the list of GPOs using the FQDN of the domain controller (e.g. adc.example.com), whereas the list of GPO URLs only included the domain name (e.g. example.com). This meant that when downloading the actual GPO data, libsmbclient would try to autodiscover a domain controller from which to perform the download, given only the domain name. In some cases, especially complicated AD deployments with lots of DCs, libsmbclient could autoresolve to an unhealthy DC (we take unhealthy to mean any DC from which GPO files cannot be downloaded, regardless of reason). This would fail the GPO download with a cryptic "invalid argument" error. Besides the chance of the above happening, autodiscovery also takes longer as opposed to passing a valid DC FQDN to libsmbclient from the start. To fix this, we rewrite the GPO URL in the gPCFileSysPath field to include the FQDN of the domain controller which essentially ensures the DC we get the GPO list from, and the DC we download the GPO data from are the same, minimizing the chance of mismatches like this occurring. This has some drawbacks in the integration tests where we set up a real SMB share and download from it, so we need to ensure the mocked server URL is the actual SMB server. Fixes #733 / UDENG-843
Bad, maybe no understandable english ahead.
Can't find anything related to this on Github, Canonical Forums, Reddit or StackOverflow.
On Ubuntu 22.04, I've followed the Wiki tutorial and verified all steps on Integration Ubuntu Desktop whitepaper. Currently using SSSD backend, I can log with Active Directory users however when adsys is installed I can't fetch GPOs. In this version the error is:
ERROR Error from server: error while updating policy: can't get policies for "ubuntu": can't download all gpos and assets: one or more error while fetching GPOs and assets: can't download "ubuntuRoot": can't check if ubuntuRoot needs refreshing: no GPT.INI file: cannot open smb://addc01.domain.com.br/SysVol/domain.com.br/Policies/{DF072E7E-6F2F-46D1-A90F-699415F72F2E}/GPT.INI: invalid argument
It happens when using
adsysctl update -moradsysctl update username@domain.com.br /tmp/krb5c_getentId_randomdnumberand justadsysctl updatetoo.I've upgrade the machine to 22.10 and the error changed to:
ERROR Error from server: error while updating policy: can't get policies for "ubuntu": failed to retrieve the list of GPO (exited with 1): exit status 1
Failed to bind - LDAP client internal error: NT_STATUS_INVALID_PARAMETER
Failed to connect to 'ldap://addc01.domain.com.br' with backend 'ldap': LDAP client internal error: NT_STATUS_INVALID_PARAMETER
Failed to open session: (1, 'LDAP client internal error: NT_STATUS_INVALID_PARAMETER').
After upgrade to 23.04 the error persist same as the above.
Full info 22.04 (-vvvv verbose):
INFO No configuration file: Config File "adsys" Not Found in "[/home/jzprates /root /etc /usr/sbin]".
We will only use the defaults, env variables or flags.
DEBUG Connecting as [[2504:109556]]
DEBUG New request /service/UpdatePolicy
DEBUG Requesting with parameters: IsComputer: true, All: false, Target: ubuntu, Krb5Cc:
DEBUG NormalizeTargetName for "ubuntu", type "computer"
DEBUG Check if grpc request peer is authorized
DEBUG Authorized as being administrator
DEBUG GetPolicies for "ubuntu", type "computer"
DEBUG Getting gpo list with arguments: "--objectclass computer ldap://addc01.domain.com.br ubuntu"
DEBUG GPO "ubuntuRoot" for "ubuntu" available at "smb://addc01.domain.com.br/SysVol/domain.com.br/Policies/{DF072E7E-6F2F-46D1-A90F-699415F72F2E}"
DEBUG Analyzing "assets"
DEBUG Analyzing "ubuntuRoot"
INFO No assets directory with GPT.INI file found on AD, skipping assets download
ERROR Error from server: error while updating policy: can't get policies for "ubuntu": can't download all gpos and assets: one or more error while fetching GPOs and assets: can't download "ubuntuRoot": can't check if ubuntuRoot needs refreshing: no GPT.INI file: cannot open smb://addc01.domain.com.br/SysVol/domain.com.br/Policies/{DF072E7E-6F2F-46D1-A90F-699415F72F2E}/GPT.INI: invalid argument
Full info 23.04 (-vvvv verbose):
INFO No configuration file: Config File "adsys" Not Found in "[/home/jzprates /root /etc /usr/sbin]".
DEBUG Connecting as [[58811:006019]]
DEBUG New request /service/UpdatePolicy
DEBUG Requesting with parameters: IsComputer: true, All: false, Target: ubuntu, Krb5Cc:
DEBUG NormalizeTargetName for "ubuntu", type "computer"
DEBUG Check if grpc request peer is authorized
DEBUG Authorized as being administrator
DEBUG GetPolicies for "ubuntu", type "computer"
DEBUG Getting gpo list with arguments: "--objectclass computer ldap://addc01.domain.com.br ubuntu"
ERROR Error from server: error while updating policy: can't get policies for "ubuntu": failed to retrieve the list of GPO (exited with 1): exit status 1
Failed to bind - LDAP client internal error: NT_STATUS_INVALID_PARAMETER
Failed to connect to 'ldap://addc01.domain.com.br' with backend 'ldap': LDAP client internal error: NT_STATUS_INVALID_PARAMETER
Failed to open session: (1, 'LDAP client internal error: NT_STATUS_INVALID_PARAMETER')
Additional info:
Domain Controller and machine are on the same subnet without firewall on any level;
Domain Controller is a Windows Server 2019 updated to the last security version;
Both machine and user are on the same OU with "no heritage" enabled and just one policy added to permit username@domain.com.br to become root;
The info header directory is "/home/jzprates" on both logs because I've collected them using the local account using "sudo adsysctl update -m -vvvv";
If I disable Adsys login on pam-auth-update, Ubuntu creates a homedir and enter correctly with domain users.
ProblemType: Bug
DistroRelease: Ubuntu 23.04
Package: adsys 0.11.0
ProcVersionSignature: Ubuntu 6.2.0-23.23-generic 6.2.12
Uname: Linux 6.2.0-23-generic x86_64
ApportVersion: 2.26.1-0ubuntu2
Architecture: amd64
CasperMD5CheckResult: pass
CurrentDesktop: ubuntu:GNOME
Date: Mon Jun 19 11:22:10 2023
InstallationDate: Installed on 2023-06-13 (5 days ago)
InstallationMedia: Ubuntu 22.04.2 LTS "Jammy Jellyfish" - Release amd64 (20230223)
RelatedPackageVersions:
sssd 2.8.1-1ubuntu1
python3-samba 2:4.17.7+dfsg-1ubuntu1
SourcePackage: adsys
UpgradeStatus: Upgraded to lunar on 2023-06-16 (2 days ago)
modified.conffile..etc.polkit-1.localauthority.conf.d.99-adsys-privilege-enforcement.conf: [deleted]
modified.conffile..etc.sudoers.d.99-adsys-privilege-enforcement: [deleted]
The text was updated successfully, but these errors were encountered: