I have a system that is joined to an AD domain via SSSD, it was happily running samba and serving shares using either kerberos or password authentication, with the update to Samba 4.7.1 in the RHEL 7.5 release, all of that stopped working.
samba config file:
[global] log level = 5
password server = * realm = AD.EXAMPLE.COM encrypt passwords = yes kerberos method = system keytab workgroup = AD server string = %h samba security = ADS map to guest = Bad User interfaces = <valid IP> hosts allow = <valid IP blocks> load printers = no passdb backend = tdbsam dns proxy = no max log size = 5000 bind interfaces only = no
restrict anonymous = 2
#============================ Share Definitions ============================== [images] comment = example images path = /var/eng/ guest ok = no printable = no write list = create mask = 0664 directory mask = 0775 read only = no valid users = +valid-example-group force group = browseable = yes
Now samba will not even start without either libwbclient or sssd-libwbclient installed with the above configuration. After installing sssd-libwbclient and modifying valid users to:
valid users = AD\valid-example-group
kerberos based connections will work just fine. However password based connections for windows systems that are not AD joined, or smbclient without kerberos, does not work. I believe this is falling back to NTLM and NTLM is simply not supported by SSSD correct?
Oddly, what used to work, with basically a call to getgrnam() no longer works in 4.7.1 release of samba and there seems to be no mention that I can find as to why. Any thoughts?
It looks an awful lot like, if we need to support both krb and password based connections we will need to use winbind, correct? Or is there another way to make this thing work? If I have to use winbind it looks like I need to use 'net ads join' or 'realm join --client-software=winbind' but it then seems to me that the system will be joined to the AD twice, once to use SSSD, and once for winbind is this correct? Is there a way to make winbind and SSSD work together?
Further it looks like, according to this: https://bugzilla.redhat.com/show_bug.cgi?id=1558560 that RHEL 7.6 with Samba 4.8.1 will require winbind to be running period. I believe that statement to be a bit of an oversimplification because sssd-libwbclient should still work, or am I misunderstanding?
Any guidance here would be great, this seems to be a fairly murky area, or my google fu is weak.
-Erinn
On Mon, Aug 27, 2018 at 05:18:01PM -0600, Erinn Looney-Triggs wrote:
I have a system that is joined to an AD domain via SSSD, it was happily running samba and serving shares using either kerberos or password authentication, with the update to Samba 4.7.1 in the RHEL 7.5 release, all of that stopped working.
samba config file:
[global] log level = 5
password server = * realm = AD.EXAMPLE.COM encrypt passwords = yes kerberos method = system keytab workgroup = AD server string = %h samba security = ADS map to guest = Bad User interfaces = <valid IP> hosts allow = <valid IP blocks> load printers = no passdb backend = tdbsam dns proxy = no max log size = 5000 bind interfaces only = no
restrict anonymous = 2
#============================ Share Definitions
[images] comment = example images path = /var/eng/ guest ok = no printable = no write list = create mask = 0664 directory mask = 0775 read only = no valid users = +valid-example-group force group = browseable = yes
Now samba will not even start without either libwbclient or sssd-libwbclient installed with the above configuration. After installing sssd-libwbclient and modifying valid users to:
valid users = AD\valid-example-group
kerberos based connections will work just fine. However password based connections for windows systems that are not AD joined, or smbclient without kerberos, does not work. I believe this is falling back to NTLM and NTLM is simply not supported by SSSD correct?
Oddly, what used to work, with basically a call to getgrnam() no longer works in 4.7.1 release of samba and there seems to be no mention that I can find as to why. Any thoughts?
It looks an awful lot like, if we need to support both krb and password based connections we will need to use winbind, correct? Or is there another way to make this thing work? If I have to use winbind it looks like I need to use 'net ads join' or 'realm join --client-software=winbind' but it then seems to me that the system will be joined to the AD twice, once to use SSSD, and once for winbind is this correct? Is there a way to make winbind and SSSD work together?
Further it looks like, according to this: https://bugzilla.redhat.com/show_bug.cgi?id=1558560 that RHEL 7.6 with Samba 4.8.1 will require winbind to be running period. I believe that statement to be a bit of an oversimplification because sssd-libwbclient should still work, or am I misunderstanding?
Any guidance here would be great, this seems to be a fairly murky area, or my google fu is weak.
Yes, if you want to use password authentication (NTLM) you have to run winbind with recent versions of Samba. The reason is that some old fallback code was removed from the smbd binary mainly for security reasons and to simplify the code in general.
If you only need Kerberos authentication sssd-libwbclient can still be used.
For all other cases where winbind must be running install Samba's libwbclient and I would recommend to use SSSD's idmap plugin for Samba/Winbind, see man idmap_sss for details.
Since idmap_sss is read-only from the winbind perspective it is recommend to have a read-write plugin as well so that the actual imap config for smb.conf might look like:
idmap config * : backend", "tdb" idmap config * : range", "10000-99999"
idmap config MYDOMAIN : backend = sss idmap config MYDOMAIN : range = 200000-2147483647
If you have a forest with multiple domains you should add a configuration for each domain with suitable ranges.
This way both SSSD and Winbind will talk to AD with the same credentials but SSSD still does all system authentication (no need to add pam_winbind to the PAM configuration) and user group lookup. Winbind will only serve the needs of smbd and other direct users of libwbclient but gets all information about idmapping from SSSD so that both Winbind and SSSD will always use the same UIDs and GIDs for the same AD object.
HTH
bye, Sumit
-Erinn
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
On 08/29/2018 02:48 AM, Sumit Bose wrote:
On Mon, Aug 27, 2018 at 05:18:01PM -0600, Erinn Looney-Triggs wrote:
I have a system that is joined to an AD domain via SSSD, it was happily running samba and serving shares using either kerberos or password authentication, with the update to Samba 4.7.1 in the RHEL 7.5 release, all of that stopped working.
samba config file:
[global] log level = 5
password server = * realm = AD.EXAMPLE.COM encrypt passwords = yes kerberos method = system keytab workgroup = AD server string = %h samba security = ADS map to guest = Bad User interfaces = <valid IP> hosts allow = <valid IP blocks> load printers = no passdb backend = tdbsam dns proxy = no max log size = 5000 bind interfaces only = no
restrict anonymous = 2
#============================ Share Definitions
[images] comment = example images path = /var/eng/ guest ok = no printable = no write list = create mask = 0664 directory mask = 0775 read only = no valid users = +valid-example-group force group = browseable = yes
Now samba will not even start without either libwbclient or sssd-libwbclient installed with the above configuration. After installing sssd-libwbclient and modifying valid users to:
valid users = AD\valid-example-group
kerberos based connections will work just fine. However password based connections for windows systems that are not AD joined, or smbclient without kerberos, does not work. I believe this is falling back to NTLM and NTLM is simply not supported by SSSD correct?
Oddly, what used to work, with basically a call to getgrnam() no longer works in 4.7.1 release of samba and there seems to be no mention that I can find as to why. Any thoughts?
It looks an awful lot like, if we need to support both krb and password based connections we will need to use winbind, correct? Or is there another way to make this thing work? If I have to use winbind it looks like I need to use 'net ads join' or 'realm join --client-software=winbind' but it then seems to me that the system will be joined to the AD twice, once to use SSSD, and once for winbind is this correct? Is there a way to make winbind and SSSD work together?
Further it looks like, according to this: https://bugzilla.redhat.com/show_bug.cgi?id=1558560 that RHEL 7.6 with Samba 4.8.1 will require winbind to be running period. I believe that statement to be a bit of an oversimplification because sssd-libwbclient should still work, or am I misunderstanding?
Any guidance here would be great, this seems to be a fairly murky area, or my google fu is weak.
Yes, if you want to use password authentication (NTLM) you have to run winbind with recent versions of Samba. The reason is that some old fallback code was removed from the smbd binary mainly for security reasons and to simplify the code in general.
If you only need Kerberos authentication sssd-libwbclient can still be used.
For all other cases where winbind must be running install Samba's libwbclient and I would recommend to use SSSD's idmap plugin for Samba/Winbind, see man idmap_sss for details.
Since idmap_sss is read-only from the winbind perspective it is recommend to have a read-write plugin as well so that the actual imap config for smb.conf might look like:
idmap config * : backend", "tdb" idmap config * : range", "10000-99999" idmap config MYDOMAIN : backend = sss idmap config MYDOMAIN : range = 200000-2147483647If you have a forest with multiple domains you should add a configuration for each domain with suitable ranges.
This way both SSSD and Winbind will talk to AD with the same credentials but SSSD still does all system authentication (no need to add pam_winbind to the PAM configuration) and user group lookup. Winbind will only serve the needs of smbd and other direct users of libwbclient but gets all information about idmapping from SSSD so that both Winbind and SSSD will always use the same UIDs and GIDs for the same AD object.
HTH
bye, Sumit
Sumit, Much appreciated, you confirmed a lot of what I suspected.
The final piece that I am trying to put together then is in effect, how to get winbind and sssd both functioning together. Remember this is on a RHEL 7.5 system.
If I simply join the system using 'realm join' winbind will not start throwing this error: Could not fetch our SID - did we join?
Running 'net ads testjoin' I end up getting prompted from the machine's kerberos password, which of course I don't have, I assume SSSD has it squirreled away somewhere.
If however, I join the system with 'realm join --client-software=winbind', 'net ads testjoin' works just fine, but I am very unsure as to whether SSSD will work in this configuration. Specifically I am concerned about the password updates for the keytab that occur and whether winbind will handle those, or sssd will try and both will step on each other. This configuration also leaves me with having to manually pull together a sssd.conf, which is fine.
I'll be investigating whether this is possible today, but any feedback is sure welcome on this.
As to ID mappings, we are actually lucky there, the AD schema has been extended with rfc2307 so UID /GID lookups can occur that way in a sane manner that is consistent across winbind and sssd.
-Erinn
-Erinn
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
On Wed, Aug 29, 2018 at 10:33:30AM -0600, Erinn Looney-Triggs wrote:
On 08/29/2018 02:48 AM, Sumit Bose wrote:
On Mon, Aug 27, 2018 at 05:18:01PM -0600, Erinn Looney-Triggs wrote:
I have a system that is joined to an AD domain via SSSD, it was happily running samba and serving shares using either kerberos or password authentication, with the update to Samba 4.7.1 in the RHEL 7.5 release, all of that stopped working.
samba config file:
[global] log level = 5
password server = * realm = AD.EXAMPLE.COM encrypt passwords = yes kerberos method = system keytab workgroup = AD server string = %h samba security = ADS map to guest = Bad User interfaces = <valid IP> hosts allow = <valid IP blocks> load printers = no passdb backend = tdbsam dns proxy = no max log size = 5000 bind interfaces only = no
restrict anonymous = 2
#============================ Share Definitions
[images] comment = example images path = /var/eng/ guest ok = no printable = no write list = create mask = 0664 directory mask = 0775 read only = no valid users = +valid-example-group force group = browseable = yes
Now samba will not even start without either libwbclient or sssd-libwbclient installed with the above configuration. After installing sssd-libwbclient and modifying valid users to:
valid users = AD\valid-example-group
kerberos based connections will work just fine. However password based connections for windows systems that are not AD joined, or smbclient without kerberos, does not work. I believe this is falling back to NTLM and NTLM is simply not supported by SSSD correct?
Oddly, what used to work, with basically a call to getgrnam() no longer works in 4.7.1 release of samba and there seems to be no mention that I can find as to why. Any thoughts?
It looks an awful lot like, if we need to support both krb and password based connections we will need to use winbind, correct? Or is there another way to make this thing work? If I have to use winbind it looks like I need to use 'net ads join' or 'realm join --client-software=winbind' but it then seems to me that the system will be joined to the AD twice, once to use SSSD, and once for winbind is this correct? Is there a way to make winbind and SSSD work together?
Further it looks like, according to this: https://bugzilla.redhat.com/show_bug.cgi?id=1558560 that RHEL 7.6 with Samba 4.8.1 will require winbind to be running period. I believe that statement to be a bit of an oversimplification because sssd-libwbclient should still work, or am I misunderstanding?
Any guidance here would be great, this seems to be a fairly murky area, or my google fu is weak.
Yes, if you want to use password authentication (NTLM) you have to run winbind with recent versions of Samba. The reason is that some old fallback code was removed from the smbd binary mainly for security reasons and to simplify the code in general.
If you only need Kerberos authentication sssd-libwbclient can still be used.
For all other cases where winbind must be running install Samba's libwbclient and I would recommend to use SSSD's idmap plugin for Samba/Winbind, see man idmap_sss for details.
Since idmap_sss is read-only from the winbind perspective it is recommend to have a read-write plugin as well so that the actual imap config for smb.conf might look like:
idmap config * : backend", "tdb" idmap config * : range", "10000-99999" idmap config MYDOMAIN : backend = sss idmap config MYDOMAIN : range = 200000-2147483647If you have a forest with multiple domains you should add a configuration for each domain with suitable ranges.
This way both SSSD and Winbind will talk to AD with the same credentials but SSSD still does all system authentication (no need to add pam_winbind to the PAM configuration) and user group lookup. Winbind will only serve the needs of smbd and other direct users of libwbclient but gets all information about idmapping from SSSD so that both Winbind and SSSD will always use the same UIDs and GIDs for the same AD object.
HTH
bye, Sumit
Sumit, Much appreciated, you confirmed a lot of what I suspected.
The final piece that I am trying to put together then is in effect, how to get winbind and sssd both functioning together. Remember this is on a RHEL 7.5 system.
If I simply join the system using 'realm join' winbind will not start throwing this error: Could not fetch our SID - did we join?
Running 'net ads testjoin' I end up getting prompted from the machine's kerberos password, which of course I don't have, I assume SSSD has it squirreled away somewhere.
If however, I join the system with 'realm join --client-software=winbind', 'net ads testjoin' works just fine, but I am very unsure as to whether SSSD will work in this configuration.
Please use --membership-software=samba instead of --client-software=winbind. realmd can either use adcli or 'net ads join' to join an AD domain. adcli will only create a keytab with Kerberos key generated from the host password. But Samba and Winbind require also the plain text password in an internal database together with the domain SID and some other settings. This data is currently only added by 'net ads join' so you have to tell realm to use it is you want to use Samba or Winbind.
What puzzles me a bit is that realmd on RHEL-7.5 should pick 'net ads join' by default. Any chance you have changed the default configuration?
Specifically I am concerned about the password updates for the keytab that occur and whether winbind will handle those, or sssd will try and both will step on each other. This configuration also leaves me with having to manually pull together a sssd.conf, which is fine.
You are right, only only should handle them. I would suggest to disable the renewal on the SSSD side and let winbind do the job because of the plain text password issue (see above). If you set 'kerberos method' in smb.conf to 'system keytab' or 'secrets and keytab' I'd expect that winbind will update the keytab entries as well.
HTH
bye, Sumit
I'll be investigating whether this is possible today, but any feedback is sure welcome on this.
As to ID mappings, we are actually lucky there, the AD schema has been extended with rfc2307 so UID /GID lookups can occur that way in a sane manner that is consistent across winbind and sssd.
-Erinn
-Erinn
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
On 08/30/2018 12:59 AM, Sumit Bose wrote:
On Wed, Aug 29, 2018 at 10:33:30AM -0600, Erinn Looney-Triggs wrote:
On 08/29/2018 02:48 AM, Sumit Bose wrote:
On Mon, Aug 27, 2018 at 05:18:01PM -0600, Erinn Looney-Triggs wrote:
I have a system that is joined to an AD domain via SSSD, it was happily running samba and serving shares using either kerberos or password authentication, with the update to Samba 4.7.1 in the RHEL 7.5 release, all of that stopped working.
samba config file:
[global] log level = 5
password server = * realm = AD.EXAMPLE.COM encrypt passwords = yes kerberos method = system keytab workgroup = AD server string = %h samba security = ADS map to guest = Bad User interfaces = <valid IP> hosts allow = <valid IP blocks> load printers = no passdb backend = tdbsam dns proxy = no max log size = 5000 bind interfaces only = no
restrict anonymous = 2
#============================ Share Definitions
[images] comment = example images path = /var/eng/ guest ok = no printable = no write list = create mask = 0664 directory mask = 0775 read only = no valid users = +valid-example-group force group = browseable = yes
Now samba will not even start without either libwbclient or sssd-libwbclient installed with the above configuration. After installing sssd-libwbclient and modifying valid users to:
valid users = AD\valid-example-group
kerberos based connections will work just fine. However password based connections for windows systems that are not AD joined, or smbclient without kerberos, does not work. I believe this is falling back to NTLM and NTLM is simply not supported by SSSD correct?
Oddly, what used to work, with basically a call to getgrnam() no longer works in 4.7.1 release of samba and there seems to be no mention that I can find as to why. Any thoughts?
It looks an awful lot like, if we need to support both krb and password based connections we will need to use winbind, correct? Or is there another way to make this thing work? If I have to use winbind it looks like I need to use 'net ads join' or 'realm join --client-software=winbind' but it then seems to me that the system will be joined to the AD twice, once to use SSSD, and once for winbind is this correct? Is there a way to make winbind and SSSD work together?
Further it looks like, according to this: https://bugzilla.redhat.com/show_bug.cgi?id=1558560 that RHEL 7.6 with Samba 4.8.1 will require winbind to be running period. I believe that statement to be a bit of an oversimplification because sssd-libwbclient should still work, or am I misunderstanding?
Any guidance here would be great, this seems to be a fairly murky area, or my google fu is weak.
Yes, if you want to use password authentication (NTLM) you have to run winbind with recent versions of Samba. The reason is that some old fallback code was removed from the smbd binary mainly for security reasons and to simplify the code in general.
If you only need Kerberos authentication sssd-libwbclient can still be used.
For all other cases where winbind must be running install Samba's libwbclient and I would recommend to use SSSD's idmap plugin for Samba/Winbind, see man idmap_sss for details.
Since idmap_sss is read-only from the winbind perspective it is recommend to have a read-write plugin as well so that the actual imap config for smb.conf might look like:
idmap config * : backend", "tdb" idmap config * : range", "10000-99999" idmap config MYDOMAIN : backend = sss idmap config MYDOMAIN : range = 200000-2147483647If you have a forest with multiple domains you should add a configuration for each domain with suitable ranges.
This way both SSSD and Winbind will talk to AD with the same credentials but SSSD still does all system authentication (no need to add pam_winbind to the PAM configuration) and user group lookup. Winbind will only serve the needs of smbd and other direct users of libwbclient but gets all information about idmapping from SSSD so that both Winbind and SSSD will always use the same UIDs and GIDs for the same AD object.
HTH
bye, Sumit
Sumit, Much appreciated, you confirmed a lot of what I suspected.
The final piece that I am trying to put together then is in effect, how to get winbind and sssd both functioning together. Remember this is on a RHEL 7.5 system.
If I simply join the system using 'realm join' winbind will not start throwing this error: Could not fetch our SID - did we join?
Running 'net ads testjoin' I end up getting prompted from the machine's kerberos password, which of course I don't have, I assume SSSD has it squirreled away somewhere.
If however, I join the system with 'realm join --client-software=winbind', 'net ads testjoin' works just fine, but I am very unsure as to whether SSSD will work in this configuration.
Please use --membership-software=samba instead of --client-software=winbind. realmd can either use adcli or 'net ads join' to join an AD domain. adcli will only create a keytab with Kerberos key generated from the host password. But Samba and Winbind require also the plain text password in an internal database together with the domain SID and some other settings. This data is currently only added by 'net ads join' so you have to tell realm to use it is you want to use Samba or Winbind.
What puzzles me a bit is that realmd on RHEL-7.5 should pick 'net ads join' by default. Any chance you have changed the default configuration?
Correct, we chose the route of using adcli originally, now moving to realmd, no doubt we dug this grave ourselves, just trying to figure out how to fix it.
Specifically I am concerned about the password updates for the keytab that occur and whether winbind will handle those, or sssd will try and both will step on each other. This configuration also leaves me with having to manually pull together a sssd.conf, which is fine.
You are right, only only should handle them. I would suggest to disable the renewal on the SSSD side and let winbind do the job because of the plain text password issue (see above). If you set 'kerberos method' in smb.conf to 'system keytab' or 'secrets and keytab' I'd expect that winbind will update the keytab entries as well.
Thanks, again confirming what I learned during yesterday's research, very helpful. It looks like the following in sssd.conf will stop the renewals on the sssd end: ad_maximum_machine_account_password_age = 0
HTH
bye, Sumit
I'll be investigating whether this is possible today, but any feedback is sure welcome on this.
As to ID mappings, we are actually lucky there, the AD schema has been extended with rfc2307 so UID /GID lookups can occur that way in a sane manner that is consistent across winbind and sssd.
-Erinn
-Erinn
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
On 08/30/2018 12:59 AM, Sumit Bose wrote:
On Wed, Aug 29, 2018 at 10:33:30AM -0600, Erinn Looney-Triggs wrote:
On 08/29/2018 02:48 AM, Sumit Bose wrote:
On Mon, Aug 27, 2018 at 05:18:01PM -0600, Erinn Looney-Triggs wrote:
I have a system that is joined to an AD domain via SSSD, it was happily running samba and serving shares using either kerberos or password authentication, with the update to Samba 4.7.1 in the RHEL 7.5 release, all of that stopped working.
samba config file:
[global] log level = 5
password server = * realm = AD.EXAMPLE.COM encrypt passwords = yes kerberos method = system keytab workgroup = AD server string = %h samba security = ADS map to guest = Bad User interfaces = <valid IP> hosts allow = <valid IP blocks> load printers = no passdb backend = tdbsam dns proxy = no max log size = 5000 bind interfaces only = no
restrict anonymous = 2
#============================ Share Definitions
[images] comment = example images path = /var/eng/ guest ok = no printable = no write list = create mask = 0664 directory mask = 0775 read only = no valid users = +valid-example-group force group = browseable = yes
Now samba will not even start without either libwbclient or sssd-libwbclient installed with the above configuration. After installing sssd-libwbclient and modifying valid users to:
valid users = AD\valid-example-group
kerberos based connections will work just fine. However password based connections for windows systems that are not AD joined, or smbclient without kerberos, does not work. I believe this is falling back to NTLM and NTLM is simply not supported by SSSD correct?
Oddly, what used to work, with basically a call to getgrnam() no longer works in 4.7.1 release of samba and there seems to be no mention that I can find as to why. Any thoughts?
It looks an awful lot like, if we need to support both krb and password based connections we will need to use winbind, correct? Or is there another way to make this thing work? If I have to use winbind it looks like I need to use 'net ads join' or 'realm join --client-software=winbind' but it then seems to me that the system will be joined to the AD twice, once to use SSSD, and once for winbind is this correct? Is there a way to make winbind and SSSD work together?
Further it looks like, according to this: https://bugzilla.redhat.com/show_bug.cgi?id=1558560 that RHEL 7.6 with Samba 4.8.1 will require winbind to be running period. I believe that statement to be a bit of an oversimplification because sssd-libwbclient should still work, or am I misunderstanding?
Any guidance here would be great, this seems to be a fairly murky area, or my google fu is weak.
Yes, if you want to use password authentication (NTLM) you have to run winbind with recent versions of Samba. The reason is that some old fallback code was removed from the smbd binary mainly for security reasons and to simplify the code in general.
If you only need Kerberos authentication sssd-libwbclient can still be used.
For all other cases where winbind must be running install Samba's libwbclient and I would recommend to use SSSD's idmap plugin for Samba/Winbind, see man idmap_sss for details.
Since idmap_sss is read-only from the winbind perspective it is recommend to have a read-write plugin as well so that the actual imap config for smb.conf might look like:
idmap config * : backend", "tdb" idmap config * : range", "10000-99999" idmap config MYDOMAIN : backend = sss idmap config MYDOMAIN : range = 200000-2147483647If you have a forest with multiple domains you should add a configuration for each domain with suitable ranges.
This way both SSSD and Winbind will talk to AD with the same credentials but SSSD still does all system authentication (no need to add pam_winbind to the PAM configuration) and user group lookup. Winbind will only serve the needs of smbd and other direct users of libwbclient but gets all information about idmapping from SSSD so that both Winbind and SSSD will always use the same UIDs and GIDs for the same AD object.
HTH
bye, Sumit
Sumit, Much appreciated, you confirmed a lot of what I suspected.
The final piece that I am trying to put together then is in effect, how to get winbind and sssd both functioning together. Remember this is on a RHEL 7.5 system.
If I simply join the system using 'realm join' winbind will not start throwing this error: Could not fetch our SID - did we join?
Running 'net ads testjoin' I end up getting prompted from the machine's kerberos password, which of course I don't have, I assume SSSD has it squirreled away somewhere.
If however, I join the system with 'realm join --client-software=winbind', 'net ads testjoin' works just fine, but I am very unsure as to whether SSSD will work in this configuration.
Please use --membership-software=samba instead of --client-software=winbind. realmd can either use adcli or 'net ads join' to join an AD domain. adcli will only create a keytab with Kerberos key generated from the host password. But Samba and Winbind require also the plain text password in an internal database together with the domain SID and some other settings. This data is currently only added by 'net ads join' so you have to tell realm to use it is you want to use Samba or Winbind.
What puzzles me a bit is that realmd on RHEL-7.5 should pick 'net ads join' by default. Any chance you have changed the default configuration?
Specifically I am concerned about the password updates for the keytab that occur and whether winbind will handle those, or sssd will try and both will step on each other. This configuration also leaves me with having to manually pull together a sssd.conf, which is fine.
You are right, only only should handle them. I would suggest to disable the renewal on the SSSD side and let winbind do the job because of the plain text password issue (see above). If you set 'kerberos method' in smb.conf to 'system keytab' or 'secrets and keytab' I'd expect that winbind will update the keytab entries as well.
Sadly, winbind doesn't appear to 'do the job', see here: https://www.linux.ncsu.edu/blog/2018/03/30/potential-conflict-between-samba-... and even the workaround doesn't seem to work (though I am testing now). Further, https://bugs.freedesktop.org/show_bug.cgi?id=100118 is an RFE asking for adcli to update the password in the secrets.tdb which would go a long way toward fixing this overall issue. However, it doesn't seem to be getting much traction.
-Erinn
HTH
bye, Sumit
I'll be investigating whether this is possible today, but any feedback is sure welcome on this.
As to ID mappings, we are actually lucky there, the AD schema has been extended with rfc2307 so UID /GID lookups can occur that way in a sane manner that is consistent across winbind and sssd.
-Erinn
-Erinn
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
On 09/06/2018 11:21 AM, Erinn Looney-Triggs wrote:
On 08/30/2018 12:59 AM, Sumit Bose wrote:
On Wed, Aug 29, 2018 at 10:33:30AM -0600, Erinn Looney-Triggs wrote:
On 08/29/2018 02:48 AM, Sumit Bose wrote:
On Mon, Aug 27, 2018 at 05:18:01PM -0600, Erinn Looney-Triggs wrote:
I have a system that is joined to an AD domain via SSSD, it was happily running samba and serving shares using either kerberos or password authentication, with the update to Samba 4.7.1 in the RHEL 7.5 release, all of that stopped working.
samba config file:
[global] log level = 5
password server = * realm = AD.EXAMPLE.COM encrypt passwords = yes kerberos method = system keytab workgroup = AD server string = %h samba security = ADS map to guest = Bad User interfaces = <valid IP> hosts allow = <valid IP blocks> load printers = no passdb backend = tdbsam dns proxy = no max log size = 5000 bind interfaces only = no
restrict anonymous = 2
#============================ Share Definitions
[images] comment = example images path = /var/eng/ guest ok = no printable = no write list = create mask = 0664 directory mask = 0775 read only = no valid users = +valid-example-group force group = browseable = yes
Now samba will not even start without either libwbclient or sssd-libwbclient installed with the above configuration. After installing sssd-libwbclient and modifying valid users to:
valid users = AD\valid-example-group
kerberos based connections will work just fine. However password based connections for windows systems that are not AD joined, or smbclient without kerberos, does not work. I believe this is falling back to NTLM and NTLM is simply not supported by SSSD correct?
Oddly, what used to work, with basically a call to getgrnam() no longer works in 4.7.1 release of samba and there seems to be no mention that I can find as to why. Any thoughts?
It looks an awful lot like, if we need to support both krb and password based connections we will need to use winbind, correct? Or is there another way to make this thing work? If I have to use winbind it looks like I need to use 'net ads join' or 'realm join --client-software=winbind' but it then seems to me that the system will be joined to the AD twice, once to use SSSD, and once for winbind is this correct? Is there a way to make winbind and SSSD work together?
Further it looks like, according to this: https://bugzilla.redhat.com/show_bug.cgi?id=1558560 that RHEL 7.6 with Samba 4.8.1 will require winbind to be running period. I believe that statement to be a bit of an oversimplification because sssd-libwbclient should still work, or am I misunderstanding?
Any guidance here would be great, this seems to be a fairly murky area, or my google fu is weak.
Yes, if you want to use password authentication (NTLM) you have to run winbind with recent versions of Samba. The reason is that some old fallback code was removed from the smbd binary mainly for security reasons and to simplify the code in general.
If you only need Kerberos authentication sssd-libwbclient can still be used.
For all other cases where winbind must be running install Samba's libwbclient and I would recommend to use SSSD's idmap plugin for Samba/Winbind, see man idmap_sss for details.
Since idmap_sss is read-only from the winbind perspective it is recommend to have a read-write plugin as well so that the actual imap config for smb.conf might look like:
idmap config * : backend", "tdb" idmap config * : range", "10000-99999" idmap config MYDOMAIN : backend = sss idmap config MYDOMAIN : range = 200000-2147483647If you have a forest with multiple domains you should add a configuration for each domain with suitable ranges.
This way both SSSD and Winbind will talk to AD with the same credentials but SSSD still does all system authentication (no need to add pam_winbind to the PAM configuration) and user group lookup. Winbind will only serve the needs of smbd and other direct users of libwbclient but gets all information about idmapping from SSSD so that both Winbind and SSSD will always use the same UIDs and GIDs for the same AD object.
HTH
bye, Sumit
Sumit, Much appreciated, you confirmed a lot of what I suspected.
The final piece that I am trying to put together then is in effect, how to get winbind and sssd both functioning together. Remember this is on a RHEL 7.5 system.
If I simply join the system using 'realm join' winbind will not start throwing this error: Could not fetch our SID - did we join?
Running 'net ads testjoin' I end up getting prompted from the machine's kerberos password, which of course I don't have, I assume SSSD has it squirreled away somewhere.
If however, I join the system with 'realm join --client-software=winbind', 'net ads testjoin' works just fine, but I am very unsure as to whether SSSD will work in this configuration.
Please use --membership-software=samba instead of --client-software=winbind. realmd can either use adcli or 'net ads join' to join an AD domain. adcli will only create a keytab with Kerberos key generated from the host password. But Samba and Winbind require also the plain text password in an internal database together with the domain SID and some other settings. This data is currently only added by 'net ads join' so you have to tell realm to use it is you want to use Samba or Winbind.
What puzzles me a bit is that realmd on RHEL-7.5 should pick 'net ads join' by default. Any chance you have changed the default configuration?
Specifically I am concerned about the password updates for the keytab that occur and whether winbind will handle those, or sssd will try and both will step on each other. This configuration also leaves me with having to manually pull together a sssd.conf, which is fine.
You are right, only only should handle them. I would suggest to disable the renewal on the SSSD side and let winbind do the job because of the plain text password issue (see above). If you set 'kerberos method' in smb.conf to 'system keytab' or 'secrets and keytab' I'd expect that winbind will update the keytab entries as well.
Sadly, winbind doesn't appear to 'do the job', see here: https://www.linux.ncsu.edu/blog/2018/03/30/potential-conflict-between-samba-... and even the workaround doesn't seem to work (though I am testing now). Further, https://bugs.freedesktop.org/show_bug.cgi?id=100118 is an RFE asking for adcli to update the password in the secrets.tdb which would go a long way toward fixing this overall issue. However, it doesn't seem to be getting much traction.
After even more digging into this, the situation is a bit more complicated than it at first appears.
The only time that winbind handles machine account password changes is when 'kerberos method = secrets only' (https://bugzilla.samba.org/show_bug.cgi?id=6750), and winbind will NOT update /etc/krb5.keytab. net ads changetrustpw can be used to update the password and the keytab however it appears to not be reliable, as I was able to reproduce (https://www.linux.ncsu.edu/blog/2018/03/30/potential-conflict-between-samba-...).
As such the only real solution to the machine password conundrum at the current moment is to disable ALL automatic changes of the password, so adding 'ad_maximum_machine_account_password_age =0' to sssd.conf and having 'kerberos method' != 'secrets only' should disable all password changes.
This is not a problem per se, the AD does not enforce password changes: https://blogs.technet.microsoft.com/askds/2009/02/15/machine-account-passwor...
BUT your organization may scavenge hosts they believe are dead by looking at the time stamp on of the last password change. Something to be aware of.
-Erinn
-Erinn
HTH
bye, Sumit
I'll be investigating whether this is possible today, but any feedback is sure welcome on this.
As to ID mappings, we are actually lucky there, the AD schema has been extended with rfc2307 so UID /GID lookups can occur that way in a sane manner that is consistent across winbind and sssd.
-Erinn
-Erinn
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
On Thu, Sep 06, 2018 at 03:08:59PM -0600, Erinn Looney-Triggs wrote:
On 09/06/2018 11:21 AM, Erinn Looney-Triggs wrote:
On 08/30/2018 12:59 AM, Sumit Bose wrote:
On Wed, Aug 29, 2018 at 10:33:30AM -0600, Erinn Looney-Triggs wrote:
On 08/29/2018 02:48 AM, Sumit Bose wrote:
On Mon, Aug 27, 2018 at 05:18:01PM -0600, Erinn Looney-Triggs wrote:
I have a system that is joined to an AD domain via SSSD, it was happily running samba and serving shares using either kerberos or password authentication, with the update to Samba 4.7.1 in the RHEL 7.5 release, all of that stopped working.
samba config file:
[global] log level = 5
password server = * realm = AD.EXAMPLE.COM encrypt passwords = yes kerberos method = system keytab workgroup = AD server string = %h samba security = ADS map to guest = Bad User interfaces = <valid IP> hosts allow = <valid IP blocks> load printers = no passdb backend = tdbsam dns proxy = no max log size = 5000 bind interfaces only = no
restrict anonymous = 2
#============================ Share Definitions
[images] comment = example images path = /var/eng/ guest ok = no printable = no write list = create mask = 0664 directory mask = 0775 read only = no valid users = +valid-example-group force group = browseable = yes
Now samba will not even start without either libwbclient or sssd-libwbclient installed with the above configuration. After installing sssd-libwbclient and modifying valid users to:
valid users = AD\valid-example-group
kerberos based connections will work just fine. However password based connections for windows systems that are not AD joined, or smbclient without kerberos, does not work. I believe this is falling back to NTLM and NTLM is simply not supported by SSSD correct?
Oddly, what used to work, with basically a call to getgrnam() no longer works in 4.7.1 release of samba and there seems to be no mention that I can find as to why. Any thoughts?
It looks an awful lot like, if we need to support both krb and password based connections we will need to use winbind, correct? Or is there another way to make this thing work? If I have to use winbind it looks like I need to use 'net ads join' or 'realm join --client-software=winbind' but it then seems to me that the system will be joined to the AD twice, once to use SSSD, and once for winbind is this correct? Is there a way to make winbind and SSSD work together?
Further it looks like, according to this: https://bugzilla.redhat.com/show_bug.cgi?id=1558560 that RHEL 7.6 with Samba 4.8.1 will require winbind to be running period. I believe that statement to be a bit of an oversimplification because sssd-libwbclient should still work, or am I misunderstanding?
Any guidance here would be great, this seems to be a fairly murky area, or my google fu is weak.
Yes, if you want to use password authentication (NTLM) you have to run winbind with recent versions of Samba. The reason is that some old fallback code was removed from the smbd binary mainly for security reasons and to simplify the code in general.
If you only need Kerberos authentication sssd-libwbclient can still be used.
For all other cases where winbind must be running install Samba's libwbclient and I would recommend to use SSSD's idmap plugin for Samba/Winbind, see man idmap_sss for details.
Since idmap_sss is read-only from the winbind perspective it is recommend to have a read-write plugin as well so that the actual imap config for smb.conf might look like:
idmap config * : backend", "tdb" idmap config * : range", "10000-99999" idmap config MYDOMAIN : backend = sss idmap config MYDOMAIN : range = 200000-2147483647If you have a forest with multiple domains you should add a configuration for each domain with suitable ranges.
This way both SSSD and Winbind will talk to AD with the same credentials but SSSD still does all system authentication (no need to add pam_winbind to the PAM configuration) and user group lookup. Winbind will only serve the needs of smbd and other direct users of libwbclient but gets all information about idmapping from SSSD so that both Winbind and SSSD will always use the same UIDs and GIDs for the same AD object.
HTH
bye, Sumit
Sumit, Much appreciated, you confirmed a lot of what I suspected.
The final piece that I am trying to put together then is in effect, how to get winbind and sssd both functioning together. Remember this is on a RHEL 7.5 system.
If I simply join the system using 'realm join' winbind will not start throwing this error: Could not fetch our SID - did we join?
Running 'net ads testjoin' I end up getting prompted from the machine's kerberos password, which of course I don't have, I assume SSSD has it squirreled away somewhere.
If however, I join the system with 'realm join --client-software=winbind', 'net ads testjoin' works just fine, but I am very unsure as to whether SSSD will work in this configuration.
Please use --membership-software=samba instead of --client-software=winbind. realmd can either use adcli or 'net ads join' to join an AD domain. adcli will only create a keytab with Kerberos key generated from the host password. But Samba and Winbind require also the plain text password in an internal database together with the domain SID and some other settings. This data is currently only added by 'net ads join' so you have to tell realm to use it is you want to use Samba or Winbind.
What puzzles me a bit is that realmd on RHEL-7.5 should pick 'net ads join' by default. Any chance you have changed the default configuration?
Specifically I am concerned about the password updates for the keytab that occur and whether winbind will handle those, or sssd will try and both will step on each other. This configuration also leaves me with having to manually pull together a sssd.conf, which is fine.
You are right, only only should handle them. I would suggest to disable the renewal on the SSSD side and let winbind do the job because of the plain text password issue (see above). If you set 'kerberos method' in smb.conf to 'system keytab' or 'secrets and keytab' I'd expect that winbind will update the keytab entries as well.
Sadly, winbind doesn't appear to 'do the job', see here: https://www.linux.ncsu.edu/blog/2018/03/30/potential-conflict-between-samba-... and even the workaround doesn't seem to work (though I am testing now). Further, https://bugs.freedesktop.org/show_bug.cgi?id=100118 is an RFE asking for adcli to update the password in the secrets.tdb which would go a long way toward fixing this overall issue. However, it doesn't seem to be getting much traction.
After even more digging into this, the situation is a bit more complicated than it at first appears.
The only time that winbind handles machine account password changes is when 'kerberos method = secrets only' (https://bugzilla.samba.org/show_bug.cgi?id=6750), and winbind will NOT update /etc/krb5.keytab. net ads changetrustpw can be used to update the password and the keytab however it appears to not be reliable, as I was able to reproduce (https://www.linux.ncsu.edu/blog/2018/03/30/potential-conflict-between-samba-...).
As such the only real solution to the machine password conundrum at the current moment is to disable ALL automatic changes of the password, so adding 'ad_maximum_machine_account_password_age =0' to sssd.conf and having 'kerberos method' != 'secrets only' should disable all password changes.
This is not a problem per se, the AD does not enforce password changes: https://blogs.technet.microsoft.com/askds/2009/02/15/machine-account-passwor...
BUT your organization may scavenge hosts they believe are dead by looking at the time stamp on of the last password change. Something to be aware of.
Thank you for the research. I wasn't aware about Samba ticket #6750.
About adcli ticket #100118. I have patches for this and they are already added to upcoming RHEL and Fedora releases. The adcli repository is currently migrated by the freedesktop infra team. I'll add the patches to the adcli upstream repository when the migration is done.
If it is important in your environment to update the host keys and 'msktutil' is available on your platform it might be possible to use this as well.
bye, Sumit
-Erinn
-Erinn
HTH
bye, Sumit
I'll be investigating whether this is possible today, but any feedback is sure welcome on this.
As to ID mappings, we are actually lucky there, the AD schema has been extended with rfc2307 so UID /GID lookups can occur that way in a sane manner that is consistent across winbind and sssd.
-Erinn
-Erinn
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
On Thu, Sep 06, 2018 at 03:08:59PM -0600, Erinn Looney-Triggs wrote:
Thank you for the research. I wasn't aware about Samba ticket #6750.
About adcli ticket #100118. I have patches for this and they are already added to upcoming RHEL and Fedora releases. The adcli repository is currently migrated by the freedesktop infra team. I'll add the patches to the adcli upstream repository when the migration is done.
Sumit, Was that repo ever migrated? Doesn't appear to be but I don't want these patches to get lost in downstream only, so just checking.
Thanks, -Erinn
If it is important in your environment to update the host keys and 'msktutil' is available on your platform it might be possible to use this as well.
bye, Sumit
-Erinn
-Erinn
HTH
bye, Sumit
I'll be investigating whether this is possible today, but any
feedback
is sure welcome on this.
As to ID mappings, we are actually lucky there, the AD schema has been extended with rfc2307 so UID /GID lookups can occur that way in a sane manner that is consistent across winbind and sssd.
-Erinn
> -Erinn > > > _______________________________________________ > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org > To unsubscribe send an email to
sssd-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To unsubscribe send an email to
sssd-users-leave(a)lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
On Fri, Oct 12, 2018 at 08:12:52PM -0000, Erinn Looney-Triggs wrote:
On Thu, Sep 06, 2018 at 03:08:59PM -0600, Erinn Looney-Triggs wrote:
Thank you for the research. I wasn't aware about Samba ticket #6750.
About adcli ticket #100118. I have patches for this and they are already added to upcoming RHEL and Fedora releases. The adcli repository is currently migrated by the freedesktop infra team. I'll add the patches to the adcli upstream repository when the migration is done.
Sumit, Was that repo ever migrated? Doesn't appear to be but I don't want these patches to get lost in downstream only, so just checking.
It is still wip https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/71.
bye, Sumit
Thanks, -Erinn
If it is important in your environment to update the host keys and 'msktutil' is available on your platform it might be possible to use this as well.
bye, Sumit
-Erinn
-Erinn
HTH
bye, Sumit
I'll be investigating whether this is possible today, but any
feedback
is sure welcome on this.
As to ID mappings, we are actually lucky there, the AD schema has been extended with rfc2307 so UID /GID lookups can occur that way in a sane manner that is consistent across winbind and sssd.
-Erinn
>> -Erinn >> >> >> _______________________________________________ >> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org >> To unsubscribe send an email to
sssd-users-leave(a)lists.fedorahosted.org
>> Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
>> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
> _______________________________________________ > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org > To unsubscribe send an email to
sssd-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
sssd-users@lists.fedorahosted.org
-
Erinn Looney-Triggs -
Sumit Bose