Do not overwrite LDAP data of local domain when looking up a Global Catalog #5351
Labels
Closed: Fixed
Issue was closed as fixed.
Comments
sumit-bose
added a commit
to sumit-bose/sssd
that referenced
this issue
Oct 6, 2020
The Global Catalog contains user and group information of the whole forest and hence any Global Catalog server can be used. Currently when a Global Catalog server is looked up the data of the LDAP server is overwritten as well. I guess the original intention was to use a single server for both services. However since the Global Catalog server can come from any domain in the forest this might overwrite the LDAP data of a DC from the local domain with the data from a AD of a remote domain and as a result lookups for users and groups from the local domain might fail since the remote DC does not has this information available at the LDAP port. In most cases this overwrite is hidden by a following lookup to find a KDC for authentication which is searched only in the local domain again where the LDAP data is overwritten again to make sure the same DC is used for LDAP and Kerberos communication. But depending on the connection timeouts and lifetime of Kerberos tickets the KDC lookup might be skipped because new credentials are not needed and as a result the wrong LDAP data is used. To avoid this the LDAP data is now only set if the current lookup is not a Global Catalog lookup. Resolves: SSSD#5351
akuster
pushed a commit
to akuster/sssd
that referenced
this issue
May 18, 2021
The Global Catalog contains user and group information of the whole forest and hence any Global Catalog server can be used. Currently when a Global Catalog server is looked up the data of the LDAP server is overwritten as well. I guess the original intention was to use a single server for both services. However since the Global Catalog server can come from any domain in the forest this might overwrite the LDAP data of a DC from the local domain with the data from a AD of a remote domain and as a result lookups for users and groups from the local domain might fail since the remote DC does not has this information available at the LDAP port. In most cases this overwrite is hidden by a following lookup to find a KDC for authentication which is searched only in the local domain again where the LDAP data is overwritten again to make sure the same DC is used for LDAP and Kerberos communication. But depending on the connection timeouts and lifetime of Kerberos tickets the KDC lookup might be skipped because new credentials are not needed and as a result the wrong LDAP data is used. To avoid this the LDAP data is now only set if the current lookup is not a Global Catalog lookup. Resolves: SSSD#5351 Reviewed-by: Pavel Březina <pbrezina@redhat.com>
sumit-bose
added a commit
to sumit-bose/sssd
that referenced
this issue
Aug 2, 2021
The Global Catalog contains user and group information of the whole forest and hence any Global Catalog server can be used. Currently when a Global Catalog server is looked up the data of the LDAP server is overwritten as well. I guess the original intention was to use a single server for both services. However since the Global Catalog server can come from any domain in the forest this might overwrite the LDAP data of a DC from the local domain with the data from a AD of a remote domain and as a result lookups for users and groups from the local domain might fail since the remote DC does not has this information available at the LDAP port. In most cases this overwrite is hidden by a following lookup to find a KDC for authentication which is searched only in the local domain again where the LDAP data is overwritten again to make sure the same DC is used for LDAP and Kerberos communication. But depending on the connection timeouts and lifetime of Kerberos tickets the KDC lookup might be skipped because new credentials are not needed and as a result the wrong LDAP data is used. To avoid this the LDAP data is now only set if the current lookup is not a Global Catalog lookup. Resolves: SSSD#5351 Reviewed-by: Pavel Březina <pbrezina@redhat.com> (cherry picked from commit 5f3b9e1)
pbrezina
pushed a commit
that referenced
this issue
Aug 9, 2021
The Global Catalog contains user and group information of the whole forest and hence any Global Catalog server can be used. Currently when a Global Catalog server is looked up the data of the LDAP server is overwritten as well. I guess the original intention was to use a single server for both services. However since the Global Catalog server can come from any domain in the forest this might overwrite the LDAP data of a DC from the local domain with the data from a AD of a remote domain and as a result lookups for users and groups from the local domain might fail since the remote DC does not has this information available at the LDAP port. In most cases this overwrite is hidden by a following lookup to find a KDC for authentication which is searched only in the local domain again where the LDAP data is overwritten again to make sure the same DC is used for LDAP and Kerberos communication. But depending on the connection timeouts and lifetime of Kerberos tickets the KDC lookup might be skipped because new credentials are not needed and as a result the wrong LDAP data is used. To avoid this the LDAP data is now only set if the current lookup is not a Global Catalog lookup. Resolves: #5351 Reviewed-by: Pavel Březina <pbrezina@redhat.com> (cherry picked from commit 5f3b9e1) Reviewed-by: Alexey Tikhonov <atikhono@redhat.com>
etrunko
pushed a commit
to etrunko/sssd
that referenced
this issue
Nov 16, 2023
The Global Catalog contains user and group information of the whole forest and hence any Global Catalog server can be used. Currently when a Global Catalog server is looked up the data of the LDAP server is overwritten as well. I guess the original intention was to use a single server for both services. However since the Global Catalog server can come from any domain in the forest this might overwrite the LDAP data of a DC from the local domain with the data from a AD of a remote domain and as a result lookups for users and groups from the local domain might fail since the remote DC does not has this information available at the LDAP port. In most cases this overwrite is hidden by a following lookup to find a KDC for authentication which is searched only in the local domain again where the LDAP data is overwritten again to make sure the same DC is used for LDAP and Kerberos communication. But depending on the connection timeouts and lifetime of Kerberos tickets the KDC lookup might be skipped because new credentials are not needed and as a result the wrong LDAP data is used. To avoid this the LDAP data is now only set if the current lookup is not a Global Catalog lookup. Resolves: SSSD#5351 Reviewed-by: Pavel Březina <pbrezina@redhat.com> (cherry picked from commit 5f3b9e1) Reviewed-by: Alexey Tikhonov <atikhono@redhat.com>
etrunko
pushed a commit
to etrunko/sssd
that referenced
this issue
Nov 16, 2023
The Global Catalog contains user and group information of the whole forest and hence any Global Catalog server can be used. Currently when a Global Catalog server is looked up the data of the LDAP server is overwritten as well. I guess the original intention was to use a single server for both services. However since the Global Catalog server can come from any domain in the forest this might overwrite the LDAP data of a DC from the local domain with the data from a AD of a remote domain and as a result lookups for users and groups from the local domain might fail since the remote DC does not has this information available at the LDAP port. In most cases this overwrite is hidden by a following lookup to find a KDC for authentication which is searched only in the local domain again where the LDAP data is overwritten again to make sure the same DC is used for LDAP and Kerberos communication. But depending on the connection timeouts and lifetime of Kerberos tickets the KDC lookup might be skipped because new credentials are not needed and as a result the wrong LDAP data is used. To avoid this the LDAP data is now only set if the current lookup is not a Global Catalog lookup. Resolves: SSSD#5351 Reviewed-by: Pavel Březina <pbrezina@redhat.com> (cherry picked from commit 5f3b9e1) Reviewed-by: Alexey Tikhonov <atikhono@redhat.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The Global Catalog contains user and group information of the whole forest and hence any Global Catalog server can be used. Currently when a Global Catalog server is looked up the data of the LDAP server is overwritten as well. I guess the original intention was to use a single server for both services.
However since the Global Catalog server can come from any domain in the forest this might overwrite the LDAP data of a DC from the local domain with the data from a AD of a remote domain and as a result lookups for users and groups from the local domain might fail since the remote DC does not has this information available at the LDAP port. In most cases this overwrite is hidden by a following lookup to find a KDC for authentication which is searched only in the local domain again where the LDAP data is overwitten again to make sure the same DC is used for LDAP and Kerberos communication. But depending on the connection timeouts and lifetime of Kerberos tickets the KDC lookup might be skipped because new credentials are not needed and as a result the wrong LDAP data is used.
I am not able to reproduce this issue properly but it can e.g. be seen in the (private) logs attached to https://bugzilla.redhat.com/show_bug.cgi?id=1695606.
The text was updated successfully, but these errors were encountered: