[SSSD-users] Re: [AD] User discovery/enumeration issue due to domain settings
On Wed, 2019-07-31 at 09:26 +0200, Jakub Hrozek wrote: > On Tue, Jul 30, 2019 at 06:42:06PM +0200, Christian Lamparter wrote: > > On Fri, 2019-07-26 at 14:08 +0200, Jakub Hrozek wrote: > > > On Fri, Jul 26, 2019 at 12:50:16PM +0200, Christian Lamparter wrote: > > > > I'm currently setting up sssd (Debian 1.16.3) on Debian Buster 10.0 > > > > and I ran into a problem that I was able to trace down to the domain > > > > permission/security settings that placed the users into a special OU > > > > that machine accounts can't read. > > > > > > > > First a bit of background: > > > > Currently, there's a way to use winbind + friends in order to join > > > > and auth users on the domain. But due to limitations (unreliable > > > > no home directories, gid/uid mapping issues, etc.), I want to give > > > > sssd a try and I tested this with both of the current Debian sssd > > > > version 1.16.3 and 2.2.0-4 (from unstable / sid / rolling release). > > > > > > > > I successfully used the "realm" utility to discover and setup the > > > > sssd.conf > > > > === > > > > # realm discover -v DOMAIN (named changed) > > > > * Resolving: _ldap._tcp.domain > > > > * Performing LDAP DSE lookup on: 1x.y.z.1 > > > > * Performing LDAP DSE lookup on: 1z.a.b.c > > > > * Performing LDAP DSE lookup on: 1d.e.f.g > > > > * Successfully discovered: domain > > > > domain > > > > type: kerberos > > > > realm-name: DOMAIN > > > > domain-name: domain > > > > 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 > > > > > > > > # realm join -v -U me@DOMAIN domain > > > > * Resolving: _ldap._tcp.domain > > > > * Performing LDAP DSE lookup on: 1x.y.z.1 > > > > * Performing LDAP DSE lookup on: 1z.a.b.c > > > > * Performing LDAP DSE lookup on: 1d.e.f.g > > > > * Successfully discovered: domain > > > > Password for me@DOMAIN: *** > > > > * Unconditionally checking packages > > > > * Resolving required packages > > > > [...] > > > > * Generated 120 character computer password > > > > * Using keytab: FILE:/etc/krb5.keytab > > > > * Found computer account for COMPUTER > > > > * Set computer password > > > > * Retrieved kvno '14' for computer account in directory: ... > > > > * Modifying computer account: userAccountControl > > > > * Modifying computer account: operatingSystemVersion, > > > > operatingSystemServicePack > > > > * Modifying computer account: userPrincipalName > > > > * Cleared old entries from keytab: FILE:/etc/krb5.keytab > > > > * Discovered which keytab salt to use > > > > * Added the entries to the keytab: ... > > > > * /usr/sbin/update-rc.d sssd enable > > > > * /usr/sbin/service sssd restart > > > > * Successfully enrolled machine in realm > > > > === > > > > > > > > /etc/sssd/sssd.conf > > > > > > > > [sssd] > > > > domains = domain > > > > config_file_version = 2 > > > > services = nss, pam, ifp # added ifp > > > > > > > > [domain/domain] > > > > ad_domain = domain > > > > krb5_realm = DOMAIN > > > > realmd_tags = manages-system joined-with-adcli > > > > cache_credentials = True > > > > id_provider = ad > > > > krb5_store_password_if_offline = True > > > > default_shell = /bin/bash > > > > ldap_id_mapping = True > > > > use_fully_qualified_names = True > > > > fallback_homedir = /home/%u@%d > > > > access_provider = ad > > > > === > > > > > > > > klist shows a valid ticket and everything seemed to be working. > > > > > > > > > > > > But when I was trying to login (yes, I made sure that my time is synced > > > > and I made sure /etc/nssswitch.conf was correct) with my "me@domain" > > > > login it never worked. I tried also id me@domain and sssctl (had to add > > > > ifp, seems like realm doesn't add) but it wasn't working for my login. > > > > > > > > After trying a lot of different combinations with different id, > > > > auth_providers and ldap I discovered that the AD Server is setup > > > > in such a way (probably due to DSVGO) that the Domain-PC Accounts > > > > are not allowed to read from the OU where all the staff users are > > > > placed. And indeed, when I copied the exact search query from the > > > > sssd_domain log with debug-level 7 and instructed > > > > ldapsearch to use GSSAPI with the Domain-PC ticket I always got a > > > > "not found". However, when I used simple bind with "me@domain" + > > > > password auth I got the request worked. > > > > > > > > So, I wonder if it is possible to extend sssd in such a way that > > > > id lookups could be performed with the provided either a provided > > > > user secret instead of the machine secret? > > > > > > Sorry, not right now. The AD provider presumes that a keytab is used. > > > But there's nothing saying that the keytab must contain a machine > > > account
[SSSD-users] Re: [AD] User discovery/enumeration issue due to domain settings
On Tue, Jul 30, 2019 at 06:42:06PM +0200, Christian Lamparter wrote: > Hello again, > > On Fri, 2019-07-26 at 14:08 +0200, Jakub Hrozek wrote: > > On Fri, Jul 26, 2019 at 12:50:16PM +0200, Christian Lamparter wrote: > > > I'm currently setting up sssd (Debian 1.16.3) on Debian Buster 10.0 > > > and I ran into a problem that I was able to trace down to the domain > > > permission/security settings that placed the users into a special OU > > > that machine accounts can't read. > > > > > > First a bit of background: > > > Currently, there's a way to use winbind + friends in order to join > > > and auth users on the domain. But due to limitations (unreliable > > > no home directories, gid/uid mapping issues, etc.), I want to give > > > sssd a try and I tested this with both of the current Debian sssd > > > version 1.16.3 and 2.2.0-4 (from unstable / sid / rolling release). > > > > > > I successfully used the "realm" utility to discover and setup the > > > sssd.conf > > > === > > > # realm discover -v DOMAIN (named changed) > > > * Resolving: _ldap._tcp.domain > > > * Performing LDAP DSE lookup on: 1x.y.z.1 > > > * Performing LDAP DSE lookup on: 1z.a.b.c > > > * Performing LDAP DSE lookup on: 1d.e.f.g > > > * Successfully discovered: domain > > > domain > > > type: kerberos > > > realm-name: DOMAIN > > > domain-name: domain > > > 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 > > > > > > # realm join -v -U me@DOMAIN domain > > > * Resolving: _ldap._tcp.domain > > > * Performing LDAP DSE lookup on: 1x.y.z.1 > > > * Performing LDAP DSE lookup on: 1z.a.b.c > > > * Performing LDAP DSE lookup on: 1d.e.f.g > > > * Successfully discovered: domain > > > Password for me@DOMAIN: *** > > > * Unconditionally checking packages > > > * Resolving required packages > > > [...] > > > * Generated 120 character computer password > > > * Using keytab: FILE:/etc/krb5.keytab > > > * Found computer account for COMPUTER > > > * Set computer password > > > * Retrieved kvno '14' for computer account in directory: ... > > > * Modifying computer account: userAccountControl > > > * Modifying computer account: operatingSystemVersion, > > > operatingSystemServicePack > > > * Modifying computer account: userPrincipalName > > > * Cleared old entries from keytab: FILE:/etc/krb5.keytab > > > * Discovered which keytab salt to use > > > * Added the entries to the keytab: ... > > > * /usr/sbin/update-rc.d sssd enable > > > * /usr/sbin/service sssd restart > > > * Successfully enrolled machine in realm > > > === > > > > > > /etc/sssd/sssd.conf > > > > > > [sssd] > > > domains = domain > > > config_file_version = 2 > > > services = nss, pam, ifp # added ifp > > > > > > [domain/domain] > > > ad_domain = domain > > > krb5_realm = DOMAIN > > > realmd_tags = manages-system joined-with-adcli > > > cache_credentials = True > > > id_provider = ad > > > krb5_store_password_if_offline = True > > > default_shell = /bin/bash > > > ldap_id_mapping = True > > > use_fully_qualified_names = True > > > fallback_homedir = /home/%u@%d > > > access_provider = ad > > > === > > > > > > klist shows a valid ticket and everything seemed to be working. > > > > > > > > > But when I was trying to login (yes, I made sure that my time is synced > > > and I made sure /etc/nssswitch.conf was correct) with my "me@domain" > > > login it never worked. I tried also id me@domain and sssctl (had to add > > > ifp, seems like realm doesn't add) but it wasn't working for my login. > > > > > > After trying a lot of different combinations with different id, > > > auth_providers and ldap I discovered that the AD Server is setup > > > in such a way (probably due to DSVGO) that the Domain-PC Accounts > > > are not allowed to read from the OU where all the staff users are > > > placed. And indeed, when I copied the exact search query from the > > > sssd_domain log with debug-level 7 and instructed > > > ldapsearch to use GSSAPI with the Domain-PC ticket I always got a > > > "not found". However, when I used simple bind with "me@domain" + > > > password auth I got the request worked. > > > > > > So, I wonder if it is possible to extend sssd in such a way that > > > id lookups could be performed with the provided either a provided > > > user secret instead of the machine secret? > > > > Sorry, not right now. The AD provider presumes that a keytab is used. > > But there's nothing saying that the keytab must contain a machine > > account principal. I guess you could create a keytab for some user, even > > the one you used for the simple bind authentication and then instruct > > sssd with the help of ldap_sasl_authid to use your custom principal (by > > default sssd tries to search for principal
[SSSD-users] Re: [AD] User discovery/enumeration issue due to domain settings
Hello again, On Fri, 2019-07-26 at 14:08 +0200, Jakub Hrozek wrote: > On Fri, Jul 26, 2019 at 12:50:16PM +0200, Christian Lamparter wrote: > > I'm currently setting up sssd (Debian 1.16.3) on Debian Buster 10.0 > > and I ran into a problem that I was able to trace down to the domain > > permission/security settings that placed the users into a special OU > > that machine accounts can't read. > > > > First a bit of background: > > Currently, there's a way to use winbind + friends in order to join > > and auth users on the domain. But due to limitations (unreliable > > no home directories, gid/uid mapping issues, etc.), I want to give > > sssd a try and I tested this with both of the current Debian sssd > > version 1.16.3 and 2.2.0-4 (from unstable / sid / rolling release). > > > > I successfully used the "realm" utility to discover and setup the > > sssd.conf > > === > > # realm discover -v DOMAIN (named changed) > > * Resolving: _ldap._tcp.domain > > * Performing LDAP DSE lookup on: 1x.y.z.1 > > * Performing LDAP DSE lookup on: 1z.a.b.c > > * Performing LDAP DSE lookup on: 1d.e.f.g > > * Successfully discovered: domain > > domain > > type: kerberos > > realm-name: DOMAIN > > domain-name: domain > > 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 > > > > # realm join -v -U me@DOMAIN domain > > * Resolving: _ldap._tcp.domain > > * Performing LDAP DSE lookup on: 1x.y.z.1 > > * Performing LDAP DSE lookup on: 1z.a.b.c > > * Performing LDAP DSE lookup on: 1d.e.f.g > > * Successfully discovered: domain > > Password for me@DOMAIN: *** > > * Unconditionally checking packages > > * Resolving required packages > > [...] > > * Generated 120 character computer password > > * Using keytab: FILE:/etc/krb5.keytab > > * Found computer account for COMPUTER > > * Set computer password > > * Retrieved kvno '14' for computer account in directory: ... > > * Modifying computer account: userAccountControl > > * Modifying computer account: operatingSystemVersion, > > operatingSystemServicePack > > * Modifying computer account: userPrincipalName > > * Cleared old entries from keytab: FILE:/etc/krb5.keytab > > * Discovered which keytab salt to use > > * Added the entries to the keytab: ... > > * /usr/sbin/update-rc.d sssd enable > > * /usr/sbin/service sssd restart > > * Successfully enrolled machine in realm > > === > > > > /etc/sssd/sssd.conf > > > > [sssd] > > domains = domain > > config_file_version = 2 > > services = nss, pam, ifp # added ifp > > > > [domain/domain] > > ad_domain = domain > > krb5_realm = DOMAIN > > realmd_tags = manages-system joined-with-adcli > > cache_credentials = True > > id_provider = ad > > krb5_store_password_if_offline = True > > default_shell = /bin/bash > > ldap_id_mapping = True > > use_fully_qualified_names = True > > fallback_homedir = /home/%u@%d > > access_provider = ad > > === > > > > klist shows a valid ticket and everything seemed to be working. > > > > > > But when I was trying to login (yes, I made sure that my time is synced > > and I made sure /etc/nssswitch.conf was correct) with my "me@domain" > > login it never worked. I tried also id me@domain and sssctl (had to add > > ifp, seems like realm doesn't add) but it wasn't working for my login. > > > > After trying a lot of different combinations with different id, > > auth_providers and ldap I discovered that the AD Server is setup > > in such a way (probably due to DSVGO) that the Domain-PC Accounts > > are not allowed to read from the OU where all the staff users are > > placed. And indeed, when I copied the exact search query from the > > sssd_domain log with debug-level 7 and instructed > > ldapsearch to use GSSAPI with the Domain-PC ticket I always got a > > "not found". However, when I used simple bind with "me@domain" + > > password auth I got the request worked. > > > > So, I wonder if it is possible to extend sssd in such a way that > > id lookups could be performed with the provided either a provided > > user secret instead of the machine secret? > > Sorry, not right now. The AD provider presumes that a keytab is used. > But there's nothing saying that the keytab must contain a machine > account principal. I guess you could create a keytab for some user, even > the one you used for the simple bind authentication and then instruct > sssd with the help of ldap_sasl_authid to use your custom principal (by > default sssd tries to search for principal based on the host name). > > btw as a coincidence, I was looking into extending the IPA provider (which > has pretty much the same issues as the AD provider) so that a client > side certificate could be used. So in future this might also be > possible, but not right now.. Ok, thanks. I got it
[SSSD-users] Re: [AD] User discovery/enumeration issue due to domain settings
On Fri, Jul 26, 2019 at 12:50:16PM +0200, Christian Lamparter wrote: > Hello Folks, > > I'm currently setting up sssd (Debian 1.16.3) on Debian Buster 10.0 > and I ran into a problem that I was able to trace down to the domain > permission/security settings that placed the users into a special OU > that machine accounts can't read. > > First a bit of background: > Currently, there's a way to use winbind + friends in order to join > and auth users on the domain. But due to limitations (unreliable > no home directories, gid/uid mapping issues, etc.), I want to give > sssd a try and I tested this with both of the current Debian sssd > version 1.16.3 and 2.2.0-4 (from unstable / sid / rolling release). > > I successfully used the "realm" utility to discover and setup the > sssd.conf > === > # realm discover -v DOMAIN (named changed) > * Resolving: _ldap._tcp.domain > * Performing LDAP DSE lookup on: 1x.y.z.1 > * Performing LDAP DSE lookup on: 1z.a.b.c > * Performing LDAP DSE lookup on: 1d.e.f.g > * Successfully discovered: domain > domain > type: kerberos > realm-name: DOMAIN > domain-name: domain > 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 > > # realm join -v -U me@DOMAIN domain > * Resolving: _ldap._tcp.domain > * Performing LDAP DSE lookup on: 1x.y.z.1 > * Performing LDAP DSE lookup on: 1z.a.b.c > * Performing LDAP DSE lookup on: 1d.e.f.g > * Successfully discovered: domain > Password for me@DOMAIN: *** > * Unconditionally checking packages > * Resolving required packages > [...] > * Generated 120 character computer password > * Using keytab: FILE:/etc/krb5.keytab > * Found computer account for COMPUTER > * Set computer password > * Retrieved kvno '14' for computer account in directory: ... > * Modifying computer account: userAccountControl > * Modifying computer account: operatingSystemVersion, > operatingSystemServicePack > * Modifying computer account: userPrincipalName > * Cleared old entries from keytab: FILE:/etc/krb5.keytab > * Discovered which keytab salt to use > * Added the entries to the keytab: ... > * /usr/sbin/update-rc.d sssd enable > * /usr/sbin/service sssd restart > * Successfully enrolled machine in realm > === > > /etc/sssd/sssd.conf > > [sssd] > domains = domain > config_file_version = 2 > services = nss, pam, ifp # added ifp > > [domain/domain] > ad_domain = domain > krb5_realm = DOMAIN > realmd_tags = manages-system joined-with-adcli > cache_credentials = True > id_provider = ad > krb5_store_password_if_offline = True > default_shell = /bin/bash > ldap_id_mapping = True > use_fully_qualified_names = True > fallback_homedir = /home/%u@%d > access_provider = ad > === > > klist shows a valid ticket and everything seemed to be working. > > > But when I was trying to login (yes, I made sure that my time is synced > and I made sure /etc/nssswitch.conf was correct) with my "me@domain" > login it never worked. I tried also id me@domain and sssctl (had to add > ifp, seems like realm doesn't add) but it wasn't working for my login. > > After trying a lot of different combinations with different id, > auth_providers and ldap I discovered that the AD Server is setup > in such a way (probably due to DSVGO) that the Domain-PC Accounts > are not allowed to read from the OU where all the staff users are > placed. And indeed, when I copied the exact search query from the > sssd_domain log with debug-level 7 and instructed > ldapsearch to use GSSAPI with the Domain-PC ticket I always got a > "not found". However, when I used simple bind with "me@domain" + > password auth I got the request worked. > > So, I wonder if it is possible to extend sssd in such a way that > id lookups could be performed with the provided either a provided > user secret instead of the machine secret? Sorry, not right now. The AD provider presumes that a keytab is used. But there's nothing saying that the keytab must contain a machine account principal. I guess you could create a keytab for some user, even the one you used for the simple bind authentication and then instruct sssd with the help of ldap_sasl_authid to use your custom principal (by default sssd tries to search for principal based on the host name). btw as a coincidence, I was looking into extending the IPA provider (which has pretty much the same issues as the AD provider) so that a client side certificate could be used. So in future this might also be possible, but not right now.. ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines:
