Hi,
our current HOWTO[1] on connecting SSSD to an AD DC is outdated, mostly because the page still only introduces the LDAP provider. Recently, me, Sumit and Jeremy Agee wrote a new page that specifically advises to use the AD provider and also use realmd for setup: https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server
We started a new page and kept the old one around mostly because pre-1.9 versions still need the LDAP provider info.
I'd like to get some review and feedback from our community so we can link the wiki page from the front page or the documentation section. In addition to the lists, I also CC-ed the individual contributors to the original page directly..I hope that's fine.
Thank you for your comments.
[1] https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20...
On 10/04/14 15:20, Jakub Hrozek wrote:
Hi,
our current HOWTO[1] on connecting SSSD to an AD DC is outdated, mostly because the page still only introduces the LDAP provider. Recently, me, Sumit and Jeremy Agee wrote a new page that specifically advises to use the AD provider and also use realmd for setup: https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server
We started a new page and kept the old one around mostly because pre-1.9 versions still need the LDAP provider info.
I'd like to get some review and feedback from our community so we can link the wiki page from the front page or the documentation section. In addition to the lists, I also CC-ed the individual contributors to the original page directly..I hope that's fine.
Thank you for your comments.
[1] https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20... _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
I have had a quick read through and it all seems ok apart from one thing, it seems to be based on the premise that there is only one AD server available, it doesn't mention the Samba 4 AD server at all and I can assure you that it does work with Samba 4.
Rowland
On Thu, Apr 10, 2014 at 04:44:20PM +0100, Rowland Penny wrote:
On 10/04/14 15:20, Jakub Hrozek wrote:
Hi,
our current HOWTO[1] on connecting SSSD to an AD DC is outdated, mostly because the page still only introduces the LDAP provider. Recently, me, Sumit and Jeremy Agee wrote a new page that specifically advises to use the AD provider and also use realmd for setup: https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server
We started a new page and kept the old one around mostly because pre-1.9 versions still need the LDAP provider info.
I'd like to get some review and feedback from our community so we can link the wiki page from the front page or the documentation section. In addition to the lists, I also CC-ed the individual contributors to the original page directly..I hope that's fine.
Thank you for your comments.
[1] https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20... _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
I have had a quick read through and it all seems ok apart from one thing, it seems to be based on the premise that there is only one AD server available, it doesn't mention the Samba 4 AD server at all and I can assure you that it does work with Samba 4.
Rowland
Except where it doesn't because Samba 4 behaves differently from AD: https://fedorahosted.org/sssd/ticket/2311
I'm not trying to bash Samba here, really, but the AD provider has so far been tested only with real AD server. So what about saying something along the lines of "AD compatible server implementations, notably Samba 4 are currently not tested by the SSSD upstream, although we would accept any upstream bug reports from setups with a Samba 4 server".
On a side note, we're currently working on getting a Continuous Integration setup up and running. It might be prudent to include a Samba 4 server in the CI setup eventually (although probably not as a tier 1 priority) to test against.
Thanks for bringing Samba 4 up and for reading through the HOWTO!
On 10/04/14 22:53, Jakub Hrozek wrote:
On Thu, Apr 10, 2014 at 04:44:20PM +0100, Rowland Penny wrote:
On 10/04/14 15:20, Jakub Hrozek wrote:
Hi,
our current HOWTO[1] on connecting SSSD to an AD DC is outdated, mostly because the page still only introduces the LDAP provider. Recently, me, Sumit and Jeremy Agee wrote a new page that specifically advises to use the AD provider and also use realmd for setup: https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server
We started a new page and kept the old one around mostly because pre-1.9 versions still need the LDAP provider info.
I'd like to get some review and feedback from our community so we can link the wiki page from the front page or the documentation section. In addition to the lists, I also CC-ed the individual contributors to the original page directly..I hope that's fine.
Thank you for your comments.
[1] https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20... _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
I have had a quick read through and it all seems ok apart from one thing, it seems to be based on the premise that there is only one AD server available, it doesn't mention the Samba 4 AD server at all and I can assure you that it does work with Samba 4.
Rowland
Except where it doesn't because Samba 4 behaves differently from AD: https://fedorahosted.org/sssd/ticket/2311
I'm not trying to bash Samba here, really, but the AD provider has so far been tested only with real AD server. So what about saying something along the lines of "AD compatible server implementations, notably Samba 4 are currently not tested by the SSSD upstream, although we would accept any upstream bug reports from setups with a Samba 4 server".
On a side note, we're currently working on getting a Continuous Integration setup up and running. It might be prudent to include a Samba 4 server in the CI setup eventually (although probably not as a tier 1 priority) to test against.
Thanks for bringing Samba 4 up and for reading through the HOWTO! _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Hi again, well one step forward and three backwards ;-)
I did have sssd in 'ad' mode working using the packages from Timo's ppa on Ubuntu 12.04, Just moved to 14.04 (after they fixed their broken samba packages) and ARRRRGHHH, you are right, sssd doesn't work any more.
Sigh, I will just have to wait until Ubuntu fix their 1.11.5 sssd packages.
Rowland
On Fri, Apr 11, 2014 at 10:33:02AM +0100, Rowland Penny wrote:
On 10/04/14 22:53, Jakub Hrozek wrote:
On Thu, Apr 10, 2014 at 04:44:20PM +0100, Rowland Penny wrote:
On 10/04/14 15:20, Jakub Hrozek wrote:
Hi,
our current HOWTO[1] on connecting SSSD to an AD DC is outdated, mostly because the page still only introduces the LDAP provider. Recently, me, Sumit and Jeremy Agee wrote a new page that specifically advises to use the AD provider and also use realmd for setup: https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server
We started a new page and kept the old one around mostly because pre-1.9 versions still need the LDAP provider info.
I'd like to get some review and feedback from our community so we can link the wiki page from the front page or the documentation section. In addition to the lists, I also CC-ed the individual contributors to the original page directly..I hope that's fine.
Thank you for your comments.
[1] https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20... _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
I have had a quick read through and it all seems ok apart from one thing, it seems to be based on the premise that there is only one AD server available, it doesn't mention the Samba 4 AD server at all and I can assure you that it does work with Samba 4.
Rowland
Except where it doesn't because Samba 4 behaves differently from AD: https://fedorahosted.org/sssd/ticket/2311
I'm not trying to bash Samba here, really, but the AD provider has so far been tested only with real AD server. So what about saying something along the lines of "AD compatible server implementations, notably Samba 4 are currently not tested by the SSSD upstream, although we would accept any upstream bug reports from setups with a Samba 4 server".
On a side note, we're currently working on getting a Continuous Integration setup up and running. It might be prudent to include a Samba 4 server in the CI setup eventually (although probably not as a tier 1 priority) to test against.
Thanks for bringing Samba 4 up and for reading through the HOWTO! _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Hi again, well one step forward and three backwards ;-)
I did have sssd in 'ad' mode working using the packages from Timo's ppa on Ubuntu 12.04, Just moved to 14.04 (after they fixed their broken samba packages) and ARRRRGHHH, you are right, sssd doesn't work any more.
Sigh, I will just have to wait until Ubuntu fix their 1.11.5 sssd packages.
Rowland
Are you sure you're hitting #2311? The bug would cause a sssd_be crash with the following backtrace: http://paste.ubuntu.com/7228102/
We'll be releasing 1.11.5.1 today to address https://fedorahosted.org/sssd/ticket/2314 anyway, so I hope Timo would pick that release up.
On 11/04/14 10:44, Jakub Hrozek wrote:
On Fri, Apr 11, 2014 at 10:33:02AM +0100, Rowland Penny wrote:
On 10/04/14 22:53, Jakub Hrozek wrote:
On Thu, Apr 10, 2014 at 04:44:20PM +0100, Rowland Penny wrote:
On 10/04/14 15:20, Jakub Hrozek wrote:
Hi,
our current HOWTO[1] on connecting SSSD to an AD DC is outdated, mostly because the page still only introduces the LDAP provider. Recently, me, Sumit and Jeremy Agee wrote a new page that specifically advises to use the AD provider and also use realmd for setup: https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server
We started a new page and kept the old one around mostly because pre-1.9 versions still need the LDAP provider info.
I'd like to get some review and feedback from our community so we can link the wiki page from the front page or the documentation section. In addition to the lists, I also CC-ed the individual contributors to the original page directly..I hope that's fine.
Thank you for your comments.
[1] https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20... _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
I have had a quick read through and it all seems ok apart from one thing, it seems to be based on the premise that there is only one AD server available, it doesn't mention the Samba 4 AD server at all and I can assure you that it does work with Samba 4.
Rowland
Except where it doesn't because Samba 4 behaves differently from AD: https://fedorahosted.org/sssd/ticket/2311
I'm not trying to bash Samba here, really, but the AD provider has so far been tested only with real AD server. So what about saying something along the lines of "AD compatible server implementations, notably Samba 4 are currently not tested by the SSSD upstream, although we would accept any upstream bug reports from setups with a Samba 4 server".
On a side note, we're currently working on getting a Continuous Integration setup up and running. It might be prudent to include a Samba 4 server in the CI setup eventually (although probably not as a tier 1 priority) to test against.
Thanks for bringing Samba 4 up and for reading through the HOWTO! _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Hi again, well one step forward and three backwards ;-)
I did have sssd in 'ad' mode working using the packages from Timo's ppa on Ubuntu 12.04, Just moved to 14.04 (after they fixed their broken samba packages) and ARRRRGHHH, you are right, sssd doesn't work any more.
Sigh, I will just have to wait until Ubuntu fix their 1.11.5 sssd packages.
Rowland
Are you sure you're hitting #2311? The bug would cause a sssd_be crash
ER, well no, all I can say is that installing sssd on Ubuntu 14.04 server by:
apt-get install sssd sssd-tools
and then setting up sssd.conf to use ad (a conf file that worked against sssd from Timo's 12.04 ppa) does not work, ps ax | grep [s]ssd returns just one line, syslog fills up with sssd trying to restart every minute or so, and the sssd logs are full of this:
(Fri Apr 11 09:32:38 2014) [sssd] [mt_svc_exit_handler] (0x0010): Process [example.com], definitely stopped!
I have now removed sssd, but I am willing to install it again, if you require more info.
Rowland
with the following backtrace: http://paste.ubuntu.com/7228102/
We'll be releasing 1.11.5.1 today to address https://fedorahosted.org/sssd/ticket/2314 anyway, so I hope Timo would pick that release up. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Fri, Apr 11, 2014 at 11:06:24AM +0100, Rowland Penny wrote:
On 11/04/14 10:44, Jakub Hrozek wrote:
On Fri, Apr 11, 2014 at 10:33:02AM +0100, Rowland Penny wrote:
On 10/04/14 22:53, Jakub Hrozek wrote:
On Thu, Apr 10, 2014 at 04:44:20PM +0100, Rowland Penny wrote:
On 10/04/14 15:20, Jakub Hrozek wrote:
Hi,
our current HOWTO[1] on connecting SSSD to an AD DC is outdated, mostly because the page still only introduces the LDAP provider. Recently, me, Sumit and Jeremy Agee wrote a new page that specifically advises to use the AD provider and also use realmd for setup: https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server
We started a new page and kept the old one around mostly because pre-1.9 versions still need the LDAP provider info.
I'd like to get some review and feedback from our community so we can link the wiki page from the front page or the documentation section. In addition to the lists, I also CC-ed the individual contributors to the original page directly..I hope that's fine.
Thank you for your comments.
[1] https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20... _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
I have had a quick read through and it all seems ok apart from one thing, it seems to be based on the premise that there is only one AD server available, it doesn't mention the Samba 4 AD server at all and I can assure you that it does work with Samba 4.
Rowland
Except where it doesn't because Samba 4 behaves differently from AD: https://fedorahosted.org/sssd/ticket/2311
I'm not trying to bash Samba here, really, but the AD provider has so far been tested only with real AD server. So what about saying something along the lines of "AD compatible server implementations, notably Samba 4 are currently not tested by the SSSD upstream, although we would accept any upstream bug reports from setups with a Samba 4 server".
On a side note, we're currently working on getting a Continuous Integration setup up and running. It might be prudent to include a Samba 4 server in the CI setup eventually (although probably not as a tier 1 priority) to test against.
Thanks for bringing Samba 4 up and for reading through the HOWTO! _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Hi again, well one step forward and three backwards ;-)
I did have sssd in 'ad' mode working using the packages from Timo's ppa on Ubuntu 12.04, Just moved to 14.04 (after they fixed their broken samba packages) and ARRRRGHHH, you are right, sssd doesn't work any more.
Sigh, I will just have to wait until Ubuntu fix their 1.11.5 sssd packages.
Rowland
Are you sure you're hitting #2311? The bug would cause a sssd_be crash
ER, well no, all I can say is that installing sssd on Ubuntu 14.04 server by:
apt-get install sssd sssd-tools
and then setting up sssd.conf to use ad (a conf file that worked against sssd from Timo's 12.04 ppa) does not work, ps ax | grep [s]ssd returns just one line, syslog fills up with sssd trying to restart every minute or so, and the sssd logs are full of this:
(Fri Apr 11 09:32:38 2014) [sssd] [mt_svc_exit_handler] (0x0010): Process [example.com], definitely stopped!
I have now removed sssd, but I am willing to install it again, if you require more info.
Rowland
Yes please, logs would also be welcome.
On 11/04/14 11:10, Jakub Hrozek wrote:
On Fri, Apr 11, 2014 at 11:06:24AM +0100, Rowland Penny wrote:
On 11/04/14 10:44, Jakub Hrozek wrote:
On Fri, Apr 11, 2014 at 10:33:02AM +0100, Rowland Penny wrote:
On 10/04/14 22:53, Jakub Hrozek wrote:
On Thu, Apr 10, 2014 at 04:44:20PM +0100, Rowland Penny wrote:
On 10/04/14 15:20, Jakub Hrozek wrote: > Hi, > > our current HOWTO[1] on connecting SSSD to an AD DC is outdated, > mostly because the page still only introduces the LDAP provider. Recently, me, > Sumit and Jeremy Agee wrote a new page that specifically advises to use > the AD provider and also use realmd for setup: > https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server > > We started a new page and kept the old one around mostly because pre-1.9 > versions still need the LDAP provider info. > > I'd like to get some review and feedback from our community so we can > link the wiki page from the front page or the documentation section. In > addition to the lists, I also CC-ed the individual contributors to the > original page directly..I hope that's fine. > > Thank you for your comments. > > [1] > https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20... > _______________________________________________ > sssd-users mailing list > sssd-users@lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/sssd-users I have had a quick read through and it all seems ok apart from one thing, it seems to be based on the premise that there is only one AD server available, it doesn't mention the Samba 4 AD server at all and I can assure you that it does work with Samba 4.
Rowland
Except where it doesn't because Samba 4 behaves differently from AD: https://fedorahosted.org/sssd/ticket/2311
I'm not trying to bash Samba here, really, but the AD provider has so far been tested only with real AD server. So what about saying something along the lines of "AD compatible server implementations, notably Samba 4 are currently not tested by the SSSD upstream, although we would accept any upstream bug reports from setups with a Samba 4 server".
On a side note, we're currently working on getting a Continuous Integration setup up and running. It might be prudent to include a Samba 4 server in the CI setup eventually (although probably not as a tier 1 priority) to test against.
Thanks for bringing Samba 4 up and for reading through the HOWTO! _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Hi again, well one step forward and three backwards ;-)
I did have sssd in 'ad' mode working using the packages from Timo's ppa on Ubuntu 12.04, Just moved to 14.04 (after they fixed their broken samba packages) and ARRRRGHHH, you are right, sssd doesn't work any more.
Sigh, I will just have to wait until Ubuntu fix their 1.11.5 sssd packages.
Rowland
Are you sure you're hitting #2311? The bug would cause a sssd_be crash
ER, well no, all I can say is that installing sssd on Ubuntu 14.04 server by:
apt-get install sssd sssd-tools
and then setting up sssd.conf to use ad (a conf file that worked against sssd from Timo's 12.04 ppa) does not work, ps ax | grep [s]ssd returns just one line, syslog fills up with sssd trying to restart every minute or so, and the sssd logs are full of this:
(Fri Apr 11 09:32:38 2014) [sssd] [mt_svc_exit_handler] (0x0010): Process [example.com], definitely stopped!
I have now removed sssd, but I am willing to install it again, if you require more info.
Rowland
Yes please, logs would also be welcome. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
OK, re-installed and sanitized logfiles attached.
Rowland
On (11/04/14 12:03), Rowland Penny wrote:
On 11/04/14 11:10, Jakub Hrozek wrote:
On Fri, Apr 11, 2014 at 11:06:24AM +0100, Rowland Penny wrote:
On 11/04/14 10:44, Jakub Hrozek wrote:
On Fri, Apr 11, 2014 at 10:33:02AM +0100, Rowland Penny wrote:
On 10/04/14 22:53, Jakub Hrozek wrote:
On Thu, Apr 10, 2014 at 04:44:20PM +0100, Rowland Penny wrote: >On 10/04/14 15:20, Jakub Hrozek wrote: >>Hi, >> >>our current HOWTO[1] on connecting SSSD to an AD DC is outdated, >>mostly because the page still only introduces the LDAP provider. Recently, me, >>Sumit and Jeremy Agee wrote a new page that specifically advises to use >>the AD provider and also use realmd for setup: >>https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server >> >>We started a new page and kept the old one around mostly because pre-1.9 >>versions still need the LDAP provider info. >> >>I'd like to get some review and feedback from our community so we can >>link the wiki page from the front page or the documentation section. In >>addition to the lists, I also CC-ed the individual contributors to the >>original page directly..I hope that's fine. >> >>Thank you for your comments. >> >>[1] >>https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20... >>_______________________________________________ >>sssd-users mailing list >>sssd-users@lists.fedorahosted.org >>https://lists.fedorahosted.org/mailman/listinfo/sssd-users >I have had a quick read through and it all seems ok apart from one >thing, it seems to be based on the premise that there is only one AD >server available, it doesn't mention the Samba 4 AD server at all >and I can assure you that it does work with Samba 4. > >Rowland Except where it doesn't because Samba 4 behaves differently from AD: https://fedorahosted.org/sssd/ticket/2311
I'm not trying to bash Samba here, really, but the AD provider has so far been tested only with real AD server. So what about saying something along the lines of "AD compatible server implementations, notably Samba 4 are currently not tested by the SSSD upstream, although we would accept any upstream bug reports from setups with a Samba 4 server".
On a side note, we're currently working on getting a Continuous Integration setup up and running. It might be prudent to include a Samba 4 server in the CI setup eventually (although probably not as a tier 1 priority) to test against.
Thanks for bringing Samba 4 up and for reading through the HOWTO! _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Hi again, well one step forward and three backwards ;-)
I did have sssd in 'ad' mode working using the packages from Timo's ppa on Ubuntu 12.04, Just moved to 14.04 (after they fixed their broken samba packages) and ARRRRGHHH, you are right, sssd doesn't work any more.
Sigh, I will just have to wait until Ubuntu fix their 1.11.5 sssd packages.
Rowland
Are you sure you're hitting #2311? The bug would cause a sssd_be crash
ER, well no, all I can say is that installing sssd on Ubuntu 14.04 server by:
apt-get install sssd sssd-tools
and then setting up sssd.conf to use ad (a conf file that worked against sssd from Timo's 12.04 ppa) does not work, ps ax | grep [s]ssd returns just one line, syslog fills up with sssd trying to restart every minute or so, and the sssd logs are full of this:
(Fri Apr 11 09:32:38 2014) [sssd] [mt_svc_exit_handler] (0x0010): Process [example.com], definitely stopped!
I have now removed sssd, but I am willing to install it again, if you require more info.
Rowland
Yes please, logs would also be welcome. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
OK, re-installed and sanitized logfiles attached.
Rowland
Log files contains nonly generic error message "Error (2) in module (ad) initialization (sssm_ad_id_init)!"
Please add debug_level = 7 into domain section. Resend log files if you don't find anything intresting.
Please change the subject of mail or send log files in new thread.
LS
On 11/04/14 12:41, Lukas Slebodnik wrote:
On (11/04/14 12:03), Rowland Penny wrote:
On 11/04/14 11:10, Jakub Hrozek wrote:
On Fri, Apr 11, 2014 at 11:06:24AM +0100, Rowland Penny wrote:
On 11/04/14 10:44, Jakub Hrozek wrote:
On Fri, Apr 11, 2014 at 10:33:02AM +0100, Rowland Penny wrote:
On 10/04/14 22:53, Jakub Hrozek wrote: > On Thu, Apr 10, 2014 at 04:44:20PM +0100, Rowland Penny wrote: >> On 10/04/14 15:20, Jakub Hrozek wrote: >>> Hi, >>> >>> our current HOWTO[1] on connecting SSSD to an AD DC is outdated, >>> mostly because the page still only introduces the LDAP provider. Recently, me, >>> Sumit and Jeremy Agee wrote a new page that specifically advises to use >>> the AD provider and also use realmd for setup: >>> https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server >>> >>> We started a new page and kept the old one around mostly because pre-1.9 >>> versions still need the LDAP provider info. >>> >>> I'd like to get some review and feedback from our community so we can >>> link the wiki page from the front page or the documentation section. In >>> addition to the lists, I also CC-ed the individual contributors to the >>> original page directly..I hope that's fine. >>> >>> Thank you for your comments. >>> >>> [1] >>> https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20... >>> _______________________________________________ >>> sssd-users mailing list >>> sssd-users@lists.fedorahosted.org >>> https://lists.fedorahosted.org/mailman/listinfo/sssd-users >> I have had a quick read through and it all seems ok apart from one >> thing, it seems to be based on the premise that there is only one AD >> server available, it doesn't mention the Samba 4 AD server at all >> and I can assure you that it does work with Samba 4. >> >> Rowland > Except where it doesn't because Samba 4 behaves differently from AD: > https://fedorahosted.org/sssd/ticket/2311 > > I'm not trying to bash Samba here, really, but the AD provider has so > far been tested only with real AD server. So what about saying something > along the lines of "AD compatible server implementations, notably Samba > 4 are currently not tested by the SSSD upstream, although we would > accept any upstream bug reports from setups with a Samba 4 server". > > On a side note, we're currently working on getting a Continuous Integration > setup up and running. It might be prudent to include a Samba 4 server in > the CI setup eventually (although probably not as a tier 1 priority) to > test against. > > Thanks for bringing Samba 4 up and for reading through the HOWTO! > _______________________________________________ > sssd-users mailing list > sssd-users@lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/sssd-users Hi again, well one step forward and three backwards ;-)
I did have sssd in 'ad' mode working using the packages from Timo's ppa on Ubuntu 12.04, Just moved to 14.04 (after they fixed their broken samba packages) and ARRRRGHHH, you are right, sssd doesn't work any more.
Sigh, I will just have to wait until Ubuntu fix their 1.11.5 sssd packages.
Rowland
Are you sure you're hitting #2311? The bug would cause a sssd_be crash
ER, well no, all I can say is that installing sssd on Ubuntu 14.04 server by:
apt-get install sssd sssd-tools
and then setting up sssd.conf to use ad (a conf file that worked against sssd from Timo's 12.04 ppa) does not work, ps ax | grep [s]ssd returns just one line, syslog fills up with sssd trying to restart every minute or so, and the sssd logs are full of this:
(Fri Apr 11 09:32:38 2014) [sssd] [mt_svc_exit_handler] (0x0010): Process [example.com], definitely stopped!
I have now removed sssd, but I am willing to install it again, if you require more info.
Rowland
Yes please, logs would also be welcome. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
OK, re-installed and sanitized logfiles attached.
Rowland
Log files contains nonly generic error message "Error (2) in module (ad) initialization (sssm_ad_id_init)!"
Please add debug_level = 7 into domain section. Resend log files if you don't find anything intresting.
Please change the subject of mail or send log files in new thread.
LS _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
OK, I take it all back, I am stupid ;-)
Once I scanned the new logfile, it dawned on me what I had forgotten to do, so I did it and now everything seems to be working ok.
Oh, you want to know what I forgot to do?
I forgot to export the keytab ;-)
Rowland
On Fri, Apr 11, 2014 at 12:59:00PM +0100, Rowland Penny wrote:
OK, I take it all back, I am stupid ;-)
Once I scanned the new logfile, it dawned on me what I had forgotten to do, so I did it and now everything seems to be working ok.
Oh, you want to know what I forgot to do?
I forgot to export the keytab ;-)
Rowland
So the keytab was missing completely on the client? We should be more verbose about that -- was there not a syslog (journal) message or a level-0 DEBUG message? Since sssd failed to start, I think we should display why prominently.
On 11/04/14 13:16, Jakub Hrozek wrote:
On Fri, Apr 11, 2014 at 12:59:00PM +0100, Rowland Penny wrote:
OK, I take it all back, I am stupid ;-)
Once I scanned the new logfile, it dawned on me what I had forgotten to do, so I did it and now everything seems to be working ok.
Oh, you want to know what I forgot to do?
I forgot to export the keytab ;-)
Rowland
So the keytab was missing completely on the client? We should be more verbose about that -- was there not a syslog (journal) message or a level-0 DEBUG message? Since sssd failed to start, I think we should display why prominently. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Hi, you have seen the relevant logs, and I couldn't see anything in them about the keytab until I raised the debug_level as you suggested, it was then obvious to me what I stupidly hadn't done. ;-)
Note: I am not blaming sssd for the lack of a keytab, I should have exported it, so it is all my fault.
Rowland
On Fri, Apr 11, 2014 at 01:22:54PM +0100, Rowland Penny wrote:
On 11/04/14 13:16, Jakub Hrozek wrote:
On Fri, Apr 11, 2014 at 12:59:00PM +0100, Rowland Penny wrote:
OK, I take it all back, I am stupid ;-)
Once I scanned the new logfile, it dawned on me what I had forgotten to do, so I did it and now everything seems to be working ok.
Oh, you want to know what I forgot to do?
I forgot to export the keytab ;-)
Rowland
So the keytab was missing completely on the client? We should be more verbose about that -- was there not a syslog (journal) message or a level-0 DEBUG message? Since sssd failed to start, I think we should display why prominently. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Hi, you have seen the relevant logs, and I couldn't see anything in them about the keytab until I raised the debug_level as you suggested, it was then obvious to me what I stupidly hadn't done. ;-)
Sorry, I should have tried to reproduce the bug myself first. To my suprise, krb5_kt_resolve() returns success even if the keytab is missing, so the DEBUG message that's already in the code was never printed.
I'll send a patch to sssd-devel to fix this, thanks for reporting the bug.
Note: I am not blaming sssd for the lack of a keytab, I should have exported it, so it is all my fault.
Well, sssd should report the error in a meaningful way, not just roll over and die.
Hi Jakub,
Hopefully I’m providing a decent discussion starting point. Is placing the DC into resolv.conf the typical scenario? Or is it more that this is the Microsoft-recommended way of doing things, full stop?
For example, I don’t put 8.8.8.8 into my resolver if I want to lookup the www.google.com A record. I suspect internal zones at companies are not resolved by adding more and more lines to the resolv.conf file. I would rather think that corporate computers will generally point at a corporate DNS server which knows how to delegate AD queries to the AD servers, and other queries to other servers, and so on. But I could be overly optimistic after reading the responses on another list (I recently asked this to the bind folks, and they brought up a lot of interesting points).
https://lists.isc.org/pipermail/bind-users/2014-April/092919.html
Thanks for providing the tutorials. The previous 2008 R2 tutorial was very useful.
V/r, Bryan
On Apr 10, 2014, at 10:20 AM, Jakub Hrozek jhrozek@redhat.com wrote:
Hi,
our current HOWTO[1] on connecting SSSD to an AD DC is outdated, mostly because the page still only introduces the LDAP provider. Recently, me, Sumit and Jeremy Agee wrote a new page that specifically advises to use the AD provider and also use realmd for setup: https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server
We started a new page and kept the old one around mostly because pre-1.9 versions still need the LDAP provider info.
I'd like to get some review and feedback from our community so we can link the wiki page from the front page or the documentation section. In addition to the lists, I also CC-ed the individual contributors to the original page directly..I hope that's fine.
Thank you for your comments.
[1] https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20... _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Thu, Apr 10, 2014 at 07:13:56PM -0400, Bryan Harris wrote:
Hi Jakub,
Hopefully I’m providing a decent discussion starting point. Is placing the DC into resolv.conf the typical scenario? Or is it more that this is the Microsoft-recommended way of doing things, full stop?
For example, I don’t put 8.8.8.8 into my resolver if I want to lookup the www.google.com A record. I suspect internal zones at companies are not resolved by adding more and more lines to the resolv.conf file. I would rather think that corporate computers will generally point at a corporate DNS server which knows how to delegate AD queries to the AD servers, and other queries to other servers, and so on. But I could be overly optimistic after reading the responses on another list (I recently asked this to the bind folks, and they brought up a lot of interesting points).
I think the point is to enable the client machine to connect to the appropriate DC, typically by resolving SRV DNS records. It's not strictly needed to query the DC itself as long as the records are available.
DNS updates are performed against the DC SSSD is connected to, resolv.conf is not used during a DNS update.
On 04/10/2014 04:20 PM, Jakub Hrozek wrote:
Hi,
our current HOWTO[1] on connecting SSSD to an AD DC is outdated, mostly because the page still only introduces the LDAP provider. Recently, me, Sumit and Jeremy Agee wrote a new page that specifically advises to use the AD provider and also use realmd for setup: https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server
We started a new page and kept the old one around mostly because pre-1.9 versions still need the LDAP provider info.
I'd like to get some review and feedback from our community so we can link the wiki page from the front page or the documentation section. In addition to the lists, I also CC-ed the individual contributors to the original page directly..I hope that's fine.
Thank you for your comments.
[1] https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20...
Hi, nice article. I have just few nitpicks to sssd.conf.
[sssd] config_file_version = 2 domains = ad.example.com services = nss, pam
[domain/ad.example.com] # Uncomment if you need offline logins # cache_credentials = true
id_provider = ad auth_provider = ad access_provider = ad
I think presenting a minimal configuration would be better, ie removing auth and access providers since they are inherited from id.
# Uncomment if service discovery is not working # ad_server = server.ad.example.com
# Uncomment if you want to use POSIX UIDs and GIDs # ldap_id_mapping = False
IMHO this description is a little bit misleading. Since you use UIDs and GIDs event it id mapping is turned on. It should say "if you have UIDs and GIDs set on AD side" or something similar.
# Comment out if the users have the shell and home dir set on the AD side default_shell = /bin/bash fallback_homedir = /home/%d/%u
# Uncomment and adjust if the default principal SHORTNAME$@REALM is not available # ldap_sasl_authid = host/client.ad.example.com@AD.EXAMPLE.COM
# Comment out if you prefer to user shortnames. use_fully_qualified_names = True
On Fri, Apr 11, 2014 at 01:11:40PM +0200, Pavel Březina wrote:
On 04/10/2014 04:20 PM, Jakub Hrozek wrote:
Hi,
our current HOWTO[1] on connecting SSSD to an AD DC is outdated, mostly because the page still only introduces the LDAP provider. Recently, me, Sumit and Jeremy Agee wrote a new page that specifically advises to use the AD provider and also use realmd for setup: https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server
We started a new page and kept the old one around mostly because pre-1.9 versions still need the LDAP provider info.
I'd like to get some review and feedback from our community so we can link the wiki page from the front page or the documentation section. In addition to the lists, I also CC-ed the individual contributors to the original page directly..I hope that's fine.
Thank you for your comments.
[1] https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20...
Hi, nice article. I have just few nitpicks to sssd.conf.
[sssd] config_file_version = 2 domains = ad.example.com services = nss, pam
[domain/ad.example.com] # Uncomment if you need offline logins # cache_credentials = true
id_provider = ad auth_provider = ad access_provider = ad
I think presenting a minimal configuration would be better, ie removing auth and access providers since they are inherited from id.
auth is inherited, access is not. The access provider defaults to permit for all backends. We talked multiple times about changing the default, but I'm not quite sure why we didn't. I remember there was a technical reason (other than 'noone sent a patch') but I can't recall it now, sorry.
I can remove the auth_provider line, though.
# Uncomment if service discovery is not working # ad_server = server.ad.example.com
# Uncomment if you want to use POSIX UIDs and GIDs # ldap_id_mapping = False
IMHO this description is a little bit misleading. Since you use UIDs and GIDs event it id mapping is turned on. It should say "if you have UIDs and GIDs set on AD side" or something similar.
You're right, fixed with the sentence you proposed.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/11/2014 08:31 AM, Jakub Hrozek wrote:
On Fri, Apr 11, 2014 at 01:11:40PM +0200, Pavel Březina wrote:
On 04/10/2014 04:20 PM, Jakub Hrozek wrote:
Hi,
our current HOWTO[1] on connecting SSSD to an AD DC is outdated, mostly because the page still only introduces the LDAP provider. Recently, me, Sumit and Jeremy Agee wrote a new page that specifically advises to use the AD provider and also use realmd for setup: https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server
We started a new page and kept the old one around mostly because pre-1.9
versions still need the LDAP provider info.
I'd like to get some review and feedback from our community so we can link the wiki page from the front page or the documentation section. In addition to the lists, I also CC-ed the individual contributors to the original page directly..I hope that's fine.
Thank you for your comments.
[1] https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20...
Hi,
nice article. I have just few nitpicks to sssd.conf.
[sssd] config_file_version = 2 domains = ad.example.com services = nss, pam
[domain/ad.example.com] # Uncomment if you need offline logins # cache_credentials = true
id_provider = ad auth_provider = ad access_provider = ad
I think presenting a minimal configuration would be better, ie removing auth and access providers since they are inherited from id.
auth is inherited, access is not. The access provider defaults to permit for all backends. We talked multiple times about changing the default, but I'm not quite sure why we didn't. I remember there was a technical reason (other than 'noone sent a patch') but I can't recall it now, sorry.
Well, the major technical reason is that it would be a backwards-incompatible change. Updating the SSSD and changing that behavior could very easily mean suddenly locking a whole lot of people out of their system. There's really no easy way to change this unless we want to force an upgrade to set it explicitly to 'access_provider = permit', but that would still break if something like puppet overwrote it again.
On Fri, Apr 11, 2014 at 11:14:33AM -0400, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/11/2014 08:31 AM, Jakub Hrozek wrote:
On Fri, Apr 11, 2014 at 01:11:40PM +0200, Pavel Březina wrote:
On 04/10/2014 04:20 PM, Jakub Hrozek wrote:
Hi,
our current HOWTO[1] on connecting SSSD to an AD DC is outdated, mostly because the page still only introduces the LDAP provider. Recently, me, Sumit and Jeremy Agee wrote a new page that specifically advises to use the AD provider and also use realmd for setup: https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server
We started a new page and kept the old one around mostly because pre-1.9
versions still need the LDAP provider info.
I'd like to get some review and feedback from our community so we can link the wiki page from the front page or the documentation section. In addition to the lists, I also CC-ed the individual contributors to the original page directly..I hope that's fine.
Thank you for your comments.
[1] https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20...
Hi,
nice article. I have just few nitpicks to sssd.conf.
[sssd] config_file_version = 2 domains = ad.example.com services = nss, pam
[domain/ad.example.com] # Uncomment if you need offline logins # cache_credentials = true
id_provider = ad auth_provider = ad access_provider = ad
I think presenting a minimal configuration would be better, ie removing auth and access providers since they are inherited from id.
auth is inherited, access is not. The access provider defaults to permit for all backends. We talked multiple times about changing the default, but I'm not quite sure why we didn't. I remember there was a technical reason (other than 'noone sent a patch') but I can't recall it now, sorry.
Well, the major technical reason is that it would be a backwards-incompatible change. Updating the SSSD and changing that behavior could very easily mean suddenly locking a whole lot of people out of their system. There's really no easy way to change this unless we want to force an upgrade to set it explicitly to 'access_provider = permit', but that would still break if something like puppet overwrote it again.
In case of the 'ad' provider, defaulting to access_provider=ad would lock out expired accounts only, which is a good thing :-)
But I think you're right, I think we wanted to default to access_provider=ad when the ad back end was new (and had no legacy users) but found out that having a different default for the existing providers (permit) and for the new one (ad) wasn't easily possible with the current backend initialization code.
On Fri, 2014-04-11 at 11:14 -0400, Stephen Gallagher wrote:
Well, the major technical reason is that it would be a backwards-incompatible change. Updating the SSSD and changing that behavior could very easily mean suddenly locking a whole lot of people out of their system. There's really no easy way to change this unless we want to force an upgrade to set it explicitly to 'access_provider = permit', but that would still break if something like puppet overwrote it again.
Although there are risks, I think we should do it in the next major release.
Simo.
One minor thing (not sure if worth mentioning): When installing IDMU on windows server, it is quite useful to stop& disable the "server for NIS" service - it is not needed for the sssd functionality (not mentioning the security issues related to using NIS).
Ondrej ________________________________________ From: sssd-users-bounces@lists.fedorahosted.org [sssd-users-bounces@lists.fedorahosted.org] on behalf of Simo Sorce [simo@redhat.com] Sent: Friday, April 11, 2014 6:09 PM To: End-user discussions about the System Security Services Daemon Subject: Re: [SSSD-users] [SSSD] New AD provider howto
On Fri, 2014-04-11 at 11:14 -0400, Stephen Gallagher wrote:
Well, the major technical reason is that it would be a backwards-incompatible change. Updating the SSSD and changing that behavior could very easily mean suddenly locking a whole lot of people out of their system. There's really no easy way to change this unless we want to force an upgrade to set it explicitly to 'access_provider = permit', but that would still break if something like puppet overwrote it again.
Although there are risks, I think we should do it in the next major release.
Simo.
-- Simo Sorce * Red Hat, Inc * New York
_______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
I think, it is worth to mention the 'msktutil' for joining AD; it is specially useful for installing a batch of computers, Is well documented with a lot of options. It lets to join domain independent from samba, with full control on creating keytab, encryption type, required UPN/SPN names etc . In Ubuntu, package downloadable from mainstream repositories. I found this program more accurate to work with than the realmd - ok - in unstable 14.04 .
Using ad provider in multi domain environment and Global Catalog search: -do I still need the section for each subdomain in sssd.conf? Can I configure sssd only for main domain C.EXAMPLE.COM, if all subdomains {A,B,D}.C.EXAMPLE.COM don't differ?
Longina
-----Original Message----- From: sssd-users-bounces@lists.fedorahosted.org [mailto:sssd-users-bounces@lists.fedorahosted.org] On Behalf Of Ondrej Valousek Sent: 14. april 2014 11:00 To: End-user discussions about the System Security Services Daemon Subject: Re: [SSSD-users] [SSSD] New AD provider howto
One minor thing (not sure if worth mentioning): When installing IDMU on windows server, it is quite useful to stop& disable the "server for NIS" service - it is not needed for the sssd functionality (not mentioning the security issues related to using NIS).
Ondrej ________________________________________ From: sssd-users-bounces@lists.fedorahosted.org [sssd-users-bounces@lists.fedorahosted.org] on behalf of Simo Sorce [simo@redhat.com] Sent: Friday, April 11, 2014 6:09 PM To: End-user discussions about the System Security Services Daemon Subject: Re: [SSSD-users] [SSSD] New AD provider howto
On Fri, 2014-04-11 at 11:14 -0400, Stephen Gallagher wrote:
Well, the major technical reason is that it would be a backwards-incompatible change. Updating the SSSD and changing that behavior could very easily mean suddenly locking a whole lot of people out of their system. There's really no easy way to change this unless we want to force an upgrade to set it explicitly to 'access_provider = permit', but that would still break if something like puppet overwrote it again.
Although there are risks, I think we should do it in the next major release.
Simo.
-- Simo Sorce * Red Hat, Inc * New York
_______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Tue, Apr 15, 2014 at 10:42:42AM +0000, Longina Przybyszewska wrote:
I think, it is worth to mention the 'msktutil' for joining AD; it is specially useful for installing a batch of computers, Is well documented with a lot of options. It lets to join domain independent from samba, with full control on creating keytab, encryption type, required UPN/SPN names etc . In Ubuntu, package downloadable from mainstream repositories. I found this program more accurate to work with than the realmd - ok - in unstable 14.04 .
I wonder what problems you had with realmd, were any bugs logged?
Using ad provider in multi domain environment and Global Catalog search: -do I still need the section for each subdomain in sssd.conf? Can I configure sssd only for main domain C.EXAMPLE.COM, if all subdomains {A,B,D}.C.EXAMPLE.COM don't differ?
If the subdomans are all part of a single forest, then SSSD should be able to see all the domains and all their users with 1.11.x.
Longina
-----Original Message----- From: sssd-users-bounces@lists.fedorahosted.org [mailto:sssd-users-bounces@lists.fedorahosted.org] On Behalf Of Jakub Hrozek Sent: 15. april 2014 13:34 To: sssd-users@lists.fedorahosted.org Subject: Re: [SSSD-users] [SSSD] New AD provider howto
On Tue, Apr 15, 2014 at 10:42:42AM +0000, Longina Przybyszewska wrote:
I think, it is worth to mention the 'msktutil' for joining AD; it is specially useful for installing a batch of computers, Is well documented with a lot of options. It lets to join domain independent from samba, with full control on creating keytab, encryption type, required UPN/SPN names etc . In Ubuntu, package downloadable from mainstream repositories. I found this program more accurate to work with than the realmd - ok - in unstable 14.04 .
I wonder what problems you had with realmd, were any bugs logged?
I can't recall it precisely now - but as far as I remember (in Ubuntu): 1. default was to install all missing packages, and to auto-configure sssd, each time it run, very annoying- should be able to discover the first time run; 2. join-leave-join sequence didn't work; machine successfully "left" AD, but when joining again it said "already joined" (At first machine joined in default container, so I need to move it to another one) even if it was manually removed from AD. As I knew the other utility 'msktutil', I could continue working with that machine.
Using ad provider in multi domain environment and Global Catalog search: -do I still need the section for each subdomain in sssd.conf? Can I configure sssd only for main domain C.EXAMPLE.COM, if all subdomains {A,B,D}.C.EXAMPLE.COM don't differ?
If the subdomans are all part of a single forest, then SSSD should be able to see all the domains and all their users with 1.11.x.
Longina
_______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Good experience with msktutil also. Even trying to use this for Hadoop Kerberos using AD. Which isn't that easy because of all the service account's you need.
On Wed, Apr 16, 2014 at 10:29 AM, Longina Przybyszewska longina@sdu.dkwrote:
-----Original Message----- From: sssd-users-bounces@lists.fedorahosted.org [mailto: sssd-users-bounces@lists.fedorahosted.org] On Behalf Of Jakub Hrozek Sent: 15. april 2014 13:34 To: sssd-users@lists.fedorahosted.org Subject: Re: [SSSD-users] [SSSD] New AD provider howto
On Tue, Apr 15, 2014 at 10:42:42AM +0000, Longina Przybyszewska wrote:
I think, it is worth to mention the 'msktutil' for joining AD; it is specially useful for installing a batch of computers, Is well documented
with a lot of options. It lets to join domain independent from samba, with full control on creating keytab, encryption type, required UPN/SPN names etc . In Ubuntu, package downloadable from mainstream repositories.
I found this program more accurate to work with than the realmd - ok -
in unstable 14.04 .
I wonder what problems you had with realmd, were any bugs logged?
I can't recall it precisely now - but as far as I remember (in Ubuntu):
- default was to install all missing packages, and to auto-configure
sssd, each time it run, very annoying- should be able to discover the first time run; 2. join-leave-join sequence didn't work; machine successfully "left" AD, but when joining again it said "already joined" (At first machine joined in default container, so I need to move it to another one) even if it was manually removed from AD. As I knew the other utility 'msktutil', I could continue working with that machine.
Using ad provider in multi domain environment and Global Catalog search: -do I still need the section for each subdomain in sssd.conf? Can I configure sssd only for main domain C.EXAMPLE.COM, if all subdomains
{A,B,D}.C.EXAMPLE.COM don't differ?
If the subdomans are all part of a single forest, then SSSD should be able to see all the domains and all their users with 1.11.x.
Longina
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On 16.04.2014 11:29, Longina Przybyszewska wrote:
-----Original Message----- From: sssd-users-bounces@lists.fedorahosted.org [mailto:sssd-users-bounces@lists.fedorahosted.org] On Behalf Of Jakub Hrozek Sent: 15. april 2014 13:34 To: sssd-users@lists.fedorahosted.org Subject: Re: [SSSD-users] [SSSD] New AD provider howto
On Tue, Apr 15, 2014 at 10:42:42AM +0000, Longina Przybyszewska wrote:
I think, it is worth to mention the 'msktutil' for joining AD; it is specially useful for installing a batch of computers, Is well documented with a lot of options. It lets to join domain independent from samba, with full control on creating keytab, encryption type, required UPN/SPN names etc . In Ubuntu, package downloadable from mainstream repositories. I found this program more accurate to work with than the realmd - ok - in unstable 14.04 .
I wonder what problems you had with realmd, were any bugs logged?
I can't recall it precisely now - but as far as I remember (in Ubuntu):
- default was to install all missing packages, and to auto-configure sssd, each time it run, very annoying- should be able to discover the first time run;
- join-leave-join sequence didn't work; machine successfully "left" AD, but when joining again it said "already joined" (At first machine joined in default container, so I need to move it to another one) even if it was manually removed from AD.
As I knew the other utility 'msktutil', I could continue working with that machine.
I've synced realmd 0.15.0-1 from Debian to Ubuntu trusty (will be released as 14.04 tomorrow). Git log doesn't look like it should fix issues like that, but if you still find some then please file bugs.
Still, isn't it preferable to specify all domains in sssd.conf and use for each, dns_discovery_domain to speed up lookups?
_
Using ad provider in multi domain environment and Global Catalog search: -do I still need the section for each subdomain in sssd.conf? Can I configure sssd only for main domain C.EXAMPLE.COM, if all subdomains {A,B,D}.C.EXAMPLE.COM don't differ?
If the subdomans are all part of a single forest, then SSSD should be able to see all the domains and all their users with 1.11.x.
Longina
_______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Thu, Apr 24, 2014 at 12:46:46PM +0000, Longina Przybyszewska wrote:
Still, isn't it preferable to specify all domains in sssd.conf and use for each, dns_discovery_domain to speed up lookups?
I don't think so, because 1) you'd have to configure the domains on all clients and 2) You'd lose cross-domain memberships at the very least.
About dns_discovery_domain, sssd should be able to autodetect the value itself..
Hi,
On 2014-04-10 17:20, Jakub Hrozek wrote:
our current HOWTO[1] on connecting SSSD to an AD DC is outdated, mostly because the page still only introduces the LDAP provider. Recently, me, Sumit and Jeremy Agee wrote a new page that specifically advises to use the AD provider and also use realmd for setup: https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server
We started a new page and kept the old one around mostly because pre-1.9 versions still need the LDAP provider info.
I'd like to get some review and feedback from our community so we can link the wiki page from the front page or the documentation section. In addition to the lists, I also CC-ed the individual contributors to the original page directly..I hope that's fine.
I've been pretty detached from all this during the past year but perhaps that's only a good thing for the review..
In general all looks very nice and it was certainly a good move to write a new document. I have few nitpick comments, please see below and address/ignore them as you see appropriate (and please pardon me if any of these are copypastes from something I wrote for the old document :).
- I'd add LDP/ldapsearch examples to the GC section - for completeness sake I'd add dns_lookup_kdc = true and master_kdc = server.ad.example.com to the krb5.conf example - I'd add KRB5_TRACE=/dev/stdout kinit -V example somewhere, perhaps after the krb5.conf example - I would at least comment out password server in smb.conf - a bit of grouping in smb.conf might make it more readable, e.g. security/realm/workgroup could be the first block, then logging options (location+level), then server options, then client options
Cheers,
On Thu, Apr 17, 2014 at 09:05:42AM +0300, Marko Myllynen wrote:
Hi,
On 2014-04-10 17:20, Jakub Hrozek wrote:
our current HOWTO[1] on connecting SSSD to an AD DC is outdated, mostly because the page still only introduces the LDAP provider. Recently, me, Sumit and Jeremy Agee wrote a new page that specifically advises to use the AD provider and also use realmd for setup: https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server
We started a new page and kept the old one around mostly because pre-1.9 versions still need the LDAP provider info.
I'd like to get some review and feedback from our community so we can link the wiki page from the front page or the documentation section. In addition to the lists, I also CC-ed the individual contributors to the original page directly..I hope that's fine.
I've been pretty detached from all this during the past year but perhaps that's only a good thing for the review..
In general all looks very nice and it was certainly a good move to write a new document. I have few nitpick comments, please see below and address/ignore them as you see appropriate (and please pardon me if any of these are copypastes from something I wrote for the old document :).
That's exactly why I CC-ed you and the other authors of the original document -- you may remember strange quirks of the real environments :)
- I'd add LDP/ldapsearch examples to the GC section
Good idea, this might be helpful for the admin to compare the attribute set between GC and LDAP.
- for completeness sake I'd add dns_lookup_kdc = true and master_kdc =
server.ad.example.com to the krb5.conf example
I've added dns_lookup_kdc, but I'm not sure about master_kdc, why do you think it's needed? I normally prefer to stick to the defaults and let the autodiscovery do its magic.
- I'd add KRB5_TRACE=/dev/stdout kinit -V example somewhere, perhaps
after the krb5.conf example
I agree, added.
- I would at least comment out password server in smb.conf
Right, after re-reading the section in man smb.conf, I agree password server should not be used.
- a bit of grouping in smb.conf might make it more readable, e.g.
security/realm/workgroup could be the first block, then logging options (location+level), then server options, then client options
Done.
I've changed the wiki page accordingly. Thanks a lot for the suggestions!
Hi,
On 2014-04-17 13:18, Jakub Hrozek wrote:
On Thu, Apr 17, 2014 at 09:05:42AM +0300, Marko Myllynen wrote:
- for completeness sake I'd add dns_lookup_kdc = true and master_kdc =
server.ad.example.com to the krb5.conf example
I've added dns_lookup_kdc, but I'm not sure about master_kdc, why do you think it's needed? I normally prefer to stick to the defaults and let the autodiscovery do its magic.
sorry, I meant adding master_kdc commented like kdc / admin_server already are. Under certain circumstances if you wanted to force using a certain KDC it was not enough to specify kdc / admin_server, you needed also master_kdc. In the past it was undocumented and when it was discovered it explained quite a few situations. Sumit or Alexander might remember the exact details, the bug report about it being undocumented doesn't go into details: https://bugzilla.redhat.com/show_bug.cgi?id=859961.
- I would at least comment out password server in smb.conf
Right, after re-reading the section in man smb.conf, I agree password server should not be used.
What do you think about adding create krb5 conf = no?
I've changed the wiki page accordingly. Thanks a lot for the suggestions!
Glad to help!
Thanks,
Hi,
this went unanswered so ...
On 2014-04-17 14:16, Marko Myllynen wrote:
On 2014-04-17 13:18, Jakub Hrozek wrote:
On Thu, Apr 17, 2014 at 09:05:42AM +0300, Marko Myllynen wrote:
- for completeness sake I'd add dns_lookup_kdc = true and master_kdc =
server.ad.example.com to the krb5.conf example
I've added dns_lookup_kdc, but I'm not sure about master_kdc, why do you think it's needed? I normally prefer to stick to the defaults and let the autodiscovery do its magic.
sorry, I meant adding master_kdc commented like kdc / admin_server already are. Under certain circumstances if you wanted to force using a certain KDC it was not enough to specify kdc / admin_server, you needed also master_kdc. In the past it was undocumented and when it was discovered it explained quite a few situations. Sumit or Alexander might remember the exact details, the bug report about it being undocumented doesn't go into details: https://bugzilla.redhat.com/show_bug.cgi?id=859961.
I added master_kdc to the example config based on the rationale above.
Right, after re-reading the section in man smb.conf, I agree password server should not be used.
What do you think about adding create krb5 conf = no?
This seems unnecessary. So does actually currently listed client signing = yes which is IMHO ambiguous, "yes" is not documented in the man page and I don't know what would be the reason for changing this. But I didn't remove that, perhaps someone had a reason to add it there.
Thanks,
On Thu, 10 Apr 2014, Jakub Hrozek wrote:
our current HOWTO[1] on connecting SSSD to an AD DC is outdated, mostly because the page still only introduces the LDAP provider. Recently, me, Sumit and Jeremy Agee wrote a new page that specifically advises to use the AD provider and also use realmd for setup: https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server
We started a new page and kept the old one around mostly because pre-1.9 versions still need the LDAP provider info.
I'd like to get some review and feedback from our community so we can link the wiki page from the front page or the documentation section. In addition to the lists, I also CC-ed the individual contributors to the original page directly..I hope that's fine.
Thank you for your comments.
Sorry for the delay in replying, I was off on holiday so hadn't had a chance to properly look through this. The only thought I'd had so far in addition to what's been said was that I didn't like the wording in one section:
# Uncomment and adjust if the default principal SHORTNAME$@REALM is not # available # ldap_sasl_authid = host/client.ad.example.com@AD.EXAMPLE.COM
This is a guide for setting up against AD. Is there *any* realistic circumstance where SHORTNAME$@REALM won't be available?
I'd gleefully delete those two lines.
A minor issue is a slight mix of true/True/false/False. Can we pick one (I'm guessing you prefer True/False).
Possibly some more warnings around the userPrincipalName string attribute, which doesn't have to map to a user principal at all, so is a possible grenade that'll screw the setup.
jh
On 04/23/2014 05:25 AM, John Hodrien wrote:
On Thu, 10 Apr 2014, Jakub Hrozek wrote:
our current HOWTO[1] on connecting SSSD to an AD DC is outdated, mostly because the page still only introduces the LDAP provider. Recently, me, Sumit and Jeremy Agee wrote a new page that specifically advises to use the AD provider and also use realmd for setup: https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server
We started a new page and kept the old one around mostly because pre-1.9 versions still need the LDAP provider info.
I'd like to get some review and feedback from our community so we can link the wiki page from the front page or the documentation section. In addition to the lists, I also CC-ed the individual contributors to the original page directly..I hope that's fine.
Thank you for your comments.
Sorry for the delay in replying, I was off on holiday so hadn't had a chance to properly look through this. The only thought I'd had so far in addition to what's been said was that I didn't like the wording in one section:
# Uncomment and adjust if the default principal SHORTNAME$@REALM is not # available # ldap_sasl_authid = host/client.ad.example.com@AD.EXAMPLE.COM
This is a guide for setting up against AD. Is there *any* realistic circumstance where SHORTNAME$@REALM won't be available?
If someone was creating the keytab on the windows side using ktpass like the example in the Creating Service Keytab on AD section this could be needed. This is less common though and your correct in most setups it would not be needed. The powershell script in that same section would create both a host/fqdn@REALM and SHORTNAME$@REALM principle with a UPN, so the extra config line would not be needed if the keytab was create by ktpass in this way.
I'd gleefully delete those two lines.
A minor issue is a slight mix of true/True/false/False. Can we pick one (I'm guessing you prefer True/False).
Possibly some more warnings around the userPrincipalName string attribute, which doesn't have to map to a user principal at all, so is a possible grenade that'll screw the setup.
jh
On Thu, 2014-04-24 at 16:33 -0400, Jeremy Agee wrote:
On 04/23/2014 05:25 AM, John Hodrien wrote:
On Thu, 10 Apr 2014, Jakub Hrozek wrote:
our current HOWTO[1] on connecting SSSD to an AD DC is outdated, mostly because the page still only introduces the LDAP provider. Recently, me, Sumit and Jeremy Agee wrote a new page that specifically advises to use the AD provider and also use realmd for setup: https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server
We started a new page and kept the old one around mostly because pre-1.9 versions still need the LDAP provider info.
I'd like to get some review and feedback from our community so we can link the wiki page from the front page or the documentation section. In addition to the lists, I also CC-ed the individual contributors to the original page directly..I hope that's fine.
Thank you for your comments.
Sorry for the delay in replying, I was off on holiday so hadn't had a chance to properly look through this. The only thought I'd had so far in addition to what's been said was that I didn't like the wording in one section:
# Uncomment and adjust if the default principal SHORTNAME$@REALM is not # available # ldap_sasl_authid = host/client.ad.example.com@AD.EXAMPLE.COM
This is a guide for setting up against AD. Is there *any* realistic circumstance where SHORTNAME$@REALM won't be available?
If someone was creating the keytab on the windows side using ktpass like the example in the Creating Service Keytab on AD section this could be needed. This is less common though and your correct in most setups it would not be needed. The powershell script in that same section would create both a host/fqdn@REALM and SHORTNAME$@REALM principle with a UPN, so the extra config line would not be needed if the keytab was create by ktpass in this way.
Hi One other circumstance could be with a samba net ads join from a previous domain join where smb.conf did not include at least: kerberos method = system keytab line. Under these circumstances it would be necessary to issue: net ads keytab create to get the machine (and host/) key. HTH Steve
I'd gleefully delete those two lines.
A minor issue is a slight mix of true/True/false/False. Can we pick one (I'm guessing you prefer True/False).
Possibly some more warnings around the userPrincipalName string attribute, which doesn't have to map to a user principal at all, so is a possible grenade that'll screw the setup.
jh
On Fri, 25 Apr 2014, steve wrote:
On Thu, 2014-04-24 at 16:33 -0400, Jeremy Agee wrote:
On 04/23/2014 05:25 AM, John Hodrien wrote:
This is a guide for setting up against AD. Is there *any* realistic circumstance where SHORTNAME$@REALM won't be available?
If someone was creating the keytab on the windows side using ktpass like the example in the Creating Service Keytab on AD section this could be needed. This is less common though and your correct in most setups it would not be needed. The powershell script in that same section would create both a host/fqdn@REALM and SHORTNAME$@REALM principle with a UPN, so the extra config line would not be needed if the keytab was create by ktpass in this way.
Hi One other circumstance could be with a samba net ads join from a previous domain join where smb.conf did not include at least: kerberos method = system keytab line. Under these circumstances it would be necessary to issue: net ads keytab create to get the machine (and host/) key.
Yep, I can see that one.
I guess I'm personally not keen for this document to be a guide on undoing unknown broken practice. I equally could have changed the userAccountControl to break kerberos by only allowing unusable enctypes or similar, but I don't think this should go into those details. Or joining when there was an existing record in AD for a previous windows machine.
Freaky setups will go outside this document, whatever you do, but I'd choose to have that document as lithe as possible. realmd/samba/ad-server approaches are all listed as valid in different cases, with justification for why that is so.
I might also prefer a bit of a restructure as I think it's a little confusing at the minute what is required:
Joining to AD: - realmd (does everything) - manual setup - generate keytab with samba - generate keytab on ad server
jh
On Fri, 2014-04-25 at 10:08 +0100, John Hodrien wrote:
On Fri, 25 Apr 2014, steve wrote:
On Thu, 2014-04-24 at 16:33 -0400, Jeremy Agee wrote:
On 04/23/2014 05:25 AM, John Hodrien wrote:
This is a guide for setting up against AD. Is there *any* realistic circumstance where SHORTNAME$@REALM won't be available?
If someone was creating the keytab on the windows side using ktpass like the example in the Creating Service Keytab on AD section this could be needed. This is less common though and your correct in most setups it would not be needed. The powershell script in that same section would create both a host/fqdn@REALM and SHORTNAME$@REALM principle with a UPN, so the extra config line would not be needed if the keytab was create by ktpass in this way.
Hi One other circumstance could be with a samba net ads join from a previous domain join where smb.conf did not include at least: kerberos method = system keytab line. Under these circumstances it would be necessary to issue: net ads keytab create to get the machine (and host/) key.
Yep, I can see that one.
I guess I'm personally not keen for this document to be a guide on undoing unknown broken practice. I equally could have changed the userAccountControl to break kerberos by only allowing unusable enctypes or similar, but I don't think this should go into those details. Or joining when there was an existing record in AD for a previous windows machine.
Freaky setups will go outside this document, whatever you do, but I'd choose to have that document as lithe as possible.
Absolutely. Keep it really simple. We only mentioned the MACHINE$ key because we got caught out starting off with a bare-bones-new-style-minimalist-ad sssd.conf without the comments grepped. And cursed for hours afterwards.
realmd/samba/ad-server approaches are all listed as valid in different cases, with justification for why that is so.
I might also prefer a bit of a restructure as I think it's a little confusing at the minute what is required:
Joining to AD:
- realmd (does everything)
- manual setup
- generate keytab with samba
- generate keytab on ad server
jh
sssd-users@lists.fedorahosted.org
-
Bryan Harris -
Jakub Hrozek -
Jeremy Agee -
John Hodrien -
Longina Przybyszewska -
Lukas Slebodnik -
Marko Myllynen -
Ondrej Valousek -
Pavel Březina -
Pieter Baele -
Rowland Penny -
Simo Sorce -
Stephen Gallagher -
steve -
Timo Aaltonen