Discovered why DDNS was not working in this ticket: https://fedorahosted.org/sssd/ticket/2565
May I suggest that if gethostname() returns a non . name, sssd should automatically add the configured SSSD domain name in sssd.conf ( [domain/domain.name] )
Jocke
On Sat, Aug 20, 2016 at 03:51:31PM +0000, Joakim Tjernlund wrote:
Discovered why DDNS was not working in this ticket: https://fedorahosted.org/sssd/ticket/2565
May I suggest that if gethostname() returns a non . name, sssd should automatically add the configured SSSD domain name in sssd.conf ( [domain/domain.name] )
There is already a simple workaround of using ad_hostname, I honestly don't think we need to be overly smart in sssd.
On Mon, 2016-08-22 at 08:29 +0200, Jakub Hrozek wrote:
On Sat, Aug 20, 2016 at 03:51:31PM +0000, Joakim Tjernlund wrote:
Discovered why DDNS was not working in this ticket: https://fedorahosted.org/sssd/ticket/2565
May I suggest that if gethostname() returns a non . name, sssd should automatically add the configured SSSD domain name in sssd.conf ( [domain/domain.name] )
There is already a simple workaround of using ad_hostname, I honestly don't think we need to be overly smart in sssd.
It is not simple from an admin perspective, one needs to supply unique sssd.conf files for each computer. Actually, I think sssd is overly "dum" in this regard as it requires non standard hostname which includes the domain and is silent about it so you have to spend a day trying to figure out why DDNS is not working.
Lets make the standard way "just work" and have users fall back to ad_hostname for special cases. I will patch sssd here and try it out and send you a "demo" patch.
Jocke
On Mon, Aug 22, 2016 at 06:58:07AM +0000, Joakim Tjernlund wrote:
On Mon, 2016-08-22 at 08:29 +0200, Jakub Hrozek wrote:
On Sat, Aug 20, 2016 at 03:51:31PM +0000, Joakim Tjernlund wrote:
Discovered why DDNS was not working in this ticket: https://fedorahosted.org/sssd/ticket/2565
May I suggest that if gethostname() returns a non . name, sssd should automatically add the configured SSSD domain name in sssd.conf ( [domain/domain.name] )
There is already a simple workaround of using ad_hostname, I honestly don't think we need to be overly smart in sssd.
It is not simple from an admin perspective, one needs to supply unique sssd.conf files for each computer. Actually, I think sssd is overly "dum" in this regard as it requires non standard
~~~~~~~~~~~ The standard is FQDN
Ok, so you Jakub say that /etc/hostname should rather contain FQDN right? I was not sure what RedHat says in terms of "best practices" here.
But I agree the from the admin prospective, we ideally need to have the same configuration in sssd.conf being shared by all hosts. Ondrej
-----Original Message----- From: Jakub Hrozek [mailto:jhrozek@redhat.com] Sent: Monday, August 22, 2016 10:07 AM To: sssd-users@lists.fedorahosted.org Subject: [SSSD-users] Re: DDNS not working due to non FQDN hostname
On Mon, Aug 22, 2016 at 06:58:07AM +0000, Joakim Tjernlund wrote:
On Mon, 2016-08-22 at 08:29 +0200, Jakub Hrozek wrote:
On Sat, Aug 20, 2016 at 03:51:31PM +0000, Joakim Tjernlund wrote:
Discovered why DDNS was not working in this ticket: https://fedorahosted.org/sssd/ticket/2565
May I suggest that if gethostname() returns a non . name, sssd should automatically add the configured SSSD domain name in sssd.conf ( [domain/domain.name] )
There is already a simple workaround of using ad_hostname, I honestly don't think we need to be overly smart in sssd.
It is not simple from an admin perspective, one needs to supply unique sssd.conf files for each computer. Actually, I think sssd is overly "dum" in this regard as it requires non standard
~~~~~~~~~~~ The standard is FQDN _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
-----
The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications@s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18.
On Mon, Aug 22, 2016 at 08:16:36AM +0000, Ondrej Valousek wrote:
Ok, so you Jakub say that /etc/hostname should rather contain FQDN right?
No, I'm saying that gethostname()/hostname should return a FQDN. You're likely to run into all kinds of issues anyway if your system is configured with shortnames.
I was not sure what RedHat says in terms of "best practices" here.
This is upstream list, the fact that my address ends with .redhat.com is irrelevant.
But I agree the from the admin prospective, we ideally need to have the same configuration in sssd.conf being shared by all hosts. Ondrej
Ok, different words: In my case, `hostname` returns shortname, but `hostname -f` returns FQDN. Is my system configured correctly or not? Ondrej
-----Original Message----- From: Jakub Hrozek [mailto:jhrozek@redhat.com] Sent: Monday, August 22, 2016 10:24 AM To: End-user discussions about the System Security Services Daemon sssd-users@lists.fedorahosted.org Subject: [SSSD-users] Re: DDNS not working due to non FQDN hostname
On Mon, Aug 22, 2016 at 08:16:36AM +0000, Ondrej Valousek wrote:
Ok, so you Jakub say that /etc/hostname should rather contain FQDN right?
No, I'm saying that gethostname()/hostname should return a FQDN. You're likely to run into all kinds of issues anyway if your system is configured with shortnames.
I was not sure what RedHat says in terms of "best practices" here.
This is upstream list, the fact that my address ends with .redhat.com is irrelevant.
But I agree the from the admin prospective, we ideally need to have the same configuration in sssd.conf being shared by all hosts. Ondrej
_______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
-----
The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications@s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18.
On Mon, Aug 22, 2016 at 08:31:33AM +0000, Ondrej Valousek wrote:
Ok, different words: In my case, `hostname` returns shortname, but `hostname -f` returns FQDN. Is my system configured correctly or not?
it depends :)
hostname -f takes the output of hostname and canonicalizes it with the help of DNS records or in your case /etc/hosts records. What Joakim was proposing was that we do the same in sssd. But since there's no guarantee that each and every program on the system will canonicalize the hostname. Many programs and libraries have been going in the other direction (even libldap, cyrus-sasl and Kerberos) and they avoid canonicalizing the hostname unless told explicitly to do so, because in the real world, DNS is often broken, not to mention roaming clients that change networks often, etc.
I think it's safer to set the hostname to match the full name of the computer as set in the joined realm from the start. I guess what we /could/ do is to add a more generic option to tell SSSD to canonicalize the hostname on boot and then set ad_hostname/ipa_hostname/etc based on that, but I'm against canonicalization by default.
On Mon, 2016-08-22 at 10:51 +0200, Jakub Hrozek wrote:
On Mon, Aug 22, 2016 at 08:31:33AM +0000, Ondrej Valousek wrote:
Ok, different words: In my case, `hostname` returns shortname, but `hostname -f` returns FQDN. Is my system configured correctly or not?
it depends :)
hostname -f takes the output of hostname and canonicalizes it with the help of DNS records or in your case /etc/hosts records. What Joakim was proposing was that we do the same in sssd. But since there's no guarantee
Not quite, I am proposing to take the configured domain in sssd.conf, it is always there(no need for DNS etc)
that each and every program on the system will canonicalize the hostname. Many programs and libraries have been going in the other direction (even libldap, cyrus-sasl and Kerberos) and they avoid canonicalizing the hostname unless told explicitly to do so, because in the real world, DNS is often broken, not to mention roaming clients that change networks often, etc.
I think it's safer to set the hostname to match the full name of the computer as set in the joined realm from the start. I guess what we /could/ do is to add a more generic option to tell SSSD to canonicalize the hostname on boot and then set ad_hostname/ipa_hostname/etc based on that, but I'm against canonicalization by default. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
On Mon, 2016-08-22 at 10:23 +0200, Jakub Hrozek wrote:
On Mon, Aug 22, 2016 at 08:16:36AM +0000, Ondrej Valousek wrote:
Ok, so you Jakub say that /etc/hostname should rather contain FQDN right?
No, I'm saying that gethostname()/hostname should return a FQDN. You're likely to run into all kinds of issues anyway if your system is configured with shortnames.
Seems to be different "standards", each distribution seems to have selected some variant. I think claiming that "gethostname()/hostname should return a FQDN" is THE standard will not hold, but some dists has adopted this to make life easier in some areas.
I added this short patch to sssd which will at least try to do the right thing:
--- sssd-1.13.1/src/providers/ad/ad_common.c.org 2016-08-21 17:47:09.501079617 +0200 +++ sssd-1.13.1/src/providers/ad/ad_common.c 2016-08-21 17:52:13.059669848 +0200 @@ -397,6 +397,11 @@ goto done; } hostname[HOST_NAME_MAX] = '\0'; + /* If hostname is non FQDN, add ad_domain */ + if (strchr(hostname,'.') == NULL) { + strncat(hostname, ".", HOST_NAME_MAX - 1); + strncat(hostname, domain, HOST_NAME_MAX - 1); + } DEBUG(SSSDBG_CONF_SETTINGS, "Setting ad_hostname to [%s].\n", hostname); ret = dp_opt_set_string(opts->basic, AD_HOSTNAME, hostname);
I was not sure what RedHat says in terms of "best practices" here.
This is upstream list, the fact that my address ends with .redhat.com is irrelevant.
But I agree the from the admin prospective, we ideally need to have the same configuration in sssd.conf being shared by all hosts. Ondrej
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
I do not think this is a good patch - systematically. Maybe better approach is to rather use gethostbyname() than gethostname(). My 2 cents.
O.
-----Original Message----- From: Joakim Tjernlund [mailto:Joakim.Tjernlund@infinera.com] Sent: Monday, August 22, 2016 10:42 AM To: sssd-users@lists.fedorahosted.org Subject: [SSSD-users] Re: DDNS not working due to non FQDN hostname
On Mon, 2016-08-22 at 10:23 +0200, Jakub Hrozek wrote:
On Mon, Aug 22, 2016 at 08:16:36AM +0000, Ondrej Valousek wrote:
Ok, so you Jakub say that /etc/hostname should rather contain FQDN right?
No, I'm saying that gethostname()/hostname should return a FQDN. You're likely to run into all kinds of issues anyway if your system is configured with shortnames.
Seems to be different "standards", each distribution seems to have selected some variant. I think claiming that "gethostname()/hostname should return a FQDN" is THE standard will not hold, but some dists has adopted this to make life easier in some areas.
I added this short patch to sssd which will at least try to do the right thing:
--- sssd-1.13.1/src/providers/ad/ad_common.c.org 2016-08-21 17:47:09.501079617 +0200 +++ sssd-1.13.1/src/providers/ad/ad_common.c 2016-08-21 17:52:13.059669848 +0200 @@ -397,6 +397,11 @@ goto done; } hostname[HOST_NAME_MAX] = '\0'; + /* If hostname is non FQDN, add ad_domain */ + if (strchr(hostname,'.') == NULL) { + strncat(hostname, ".", HOST_NAME_MAX - 1); + strncat(hostname, domain, HOST_NAME_MAX - 1); + } DEBUG(SSSDBG_CONF_SETTINGS, "Setting ad_hostname to [%s].\n", hostname); ret = dp_opt_set_string(opts->basic, AD_HOSTNAME, hostname);
I was not sure what RedHat says in terms of "best practices" here.
This is upstream list, the fact that my address ends with .redhat.com is irrelevant.
But I agree the from the admin prospective, we ideally need to have the same configuration in sssd.conf being shared by all hosts. Ondrej
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahost ed.org
_______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
-----
The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications@s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18.
On 22.8.2016 10:49, Ondrej Valousek wrote:
I do not think this is a good patch - systematically. Maybe better approach is to rather use gethostbyname() than gethostname(). My 2 cents.
Most importantly, this will work only for the simplest possible case where host name of the client is sub-domain of AD domain.
It will break e.g. in this scenario: AD domain = example.net. Client's hostname = myclient.branch1.example.net.
Needles to say that it is perfectly valid to have client host name like client.unrelated.example.org. (not the .org at the end!).
Having said that, I believe that SSSD should not try to be smarter in this area because it cannot do better without making wrong and surprising decisions in more complicated setups.
Petr^2 Spacek
-----Original Message----- From: Joakim Tjernlund [mailto:Joakim.Tjernlund@infinera.com] Sent: Monday, August 22, 2016 10:42 AM To: sssd-users@lists.fedorahosted.org Subject: [SSSD-users] Re: DDNS not working due to non FQDN hostname
On Mon, 2016-08-22 at 10:23 +0200, Jakub Hrozek wrote:
On Mon, Aug 22, 2016 at 08:16:36AM +0000, Ondrej Valousek wrote:
Ok, so you Jakub say that /etc/hostname should rather contain FQDN right?
No, I'm saying that gethostname()/hostname should return a FQDN. You're likely to run into all kinds of issues anyway if your system is configured with shortnames.
Seems to be different "standards", each distribution seems to have selected some variant. I think claiming that "gethostname()/hostname should return a FQDN" is THE standard will not hold, but some dists has adopted this to make life easier in some areas.
I added this short patch to sssd which will at least try to do the right thing:
--- sssd-1.13.1/src/providers/ad/ad_common.c.org 2016-08-21 17:47:09.501079617 +0200 +++ sssd-1.13.1/src/providers/ad/ad_common.c 2016-08-21 17:52:13.059669848 +0200 @@ -397,6 +397,11 @@ goto done; } hostname[HOST_NAME_MAX] = '\0';
- /* If hostname is non FQDN, add ad_domain */
- if (strchr(hostname,'.') == NULL) {
strncat(hostname, ".", HOST_NAME_MAX - 1);strncat(hostname, domain, HOST_NAME_MAX - 1);- } DEBUG(SSSDBG_CONF_SETTINGS, "Setting ad_hostname to [%s].\n", hostname); ret = dp_opt_set_string(opts->basic, AD_HOSTNAME, hostname);
I was not sure what RedHat says in terms of "best practices" here.
This is upstream list, the fact that my address ends with .redhat.com is irrelevant.
But I agree the from the admin prospective, we ideally need to have the same configuration in sssd.conf being shared by all hosts. Ondrej
On Mon, 2016-08-22 at 11:13 +0200, Petr Spacek wrote:
On 22.8.2016 10:49, Ondrej Valousek wrote:
I do not think this is a good patch - systematically. Maybe better approach is to rather use gethostbyname() than gethostname(). My 2 cents.
Most importantly, this will work only for the simplest possible case where host name of the client is sub-domain of AD domain.
It will break e.g. in this scenario: AD domain = example.net. Client's hostname = myclient.branch1.example.net.
No, the patch will not touch hostname if it already have a "." in it.
Needles to say that it is perfectly valid to have client host name like client.unrelated.example.org. (not the .org at the end!).
. at the end? That is new to me
Having said that, I believe that SSSD should not try to be smarter in this area because it cannot do better without making wrong and surprising decisions in more complicated setups.
Petr^2 Spacek
-----Original Message----- From: Joakim Tjernlund [mailto:Joakim.Tjernlund@infinera.com] Sent: Monday, August 22, 2016 10:42 AM To: sssd-users@lists.fedorahosted.org Subject: [SSSD-users] Re: DDNS not working due to non FQDN hostname
On Mon, 2016-08-22 at 10:23 +0200, Jakub Hrozek wrote:
On Mon, Aug 22, 2016 at 08:16:36AM +0000, Ondrej Valousek wrote:
Ok, so you Jakub say that /etc/hostname should rather contain FQDN right?
No, I'm saying that gethostname()/hostname should return a FQDN. You're likely to run into all kinds of issues anyway if your system is configured with shortnames.
Seems to be different "standards", each distribution seems to have selected some variant. I think claiming that "gethostname()/hostname should return a FQDN" is THE standard will not hold, but some dists has adopted this to make life easier in some areas.
I added this short patch to sssd which will at least try to do the right thing:
--- sssd-1.13.1/src/providers/ad/ad_common.c.org 2016-08-21 17:47:09.501079617 +0200 +++ sssd-1.13.1/src/providers/ad/ad_common.c 2016-08-21 17:52:13.059669848 +0200 @@ -397,6 +397,11 @@ goto done; } hostname[HOST_NAME_MAX] = '\0';
- /* If hostname is non FQDN, add ad_domain */
- if (strchr(hostname,'.') == NULL) {
- strncat(hostname, ".", HOST_NAME_MAX - 1);
- strncat(hostname, domain, HOST_NAME_MAX - 1);
- }
DEBUG(SSSDBG_CONF_SETTINGS, "Setting ad_hostname to [%s].\n", hostname); ret = dp_opt_set_string(opts->basic, AD_HOSTNAME, hostname);
I was not sure what RedHat says in terms of "best practices" here.
This is upstream list, the fact that my address ends with .redhat.com is irrelevant.
But I agree the from the admin prospective, we ideally need to have the same configuration in sssd.conf being shared by all hosts. Ondrej
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
On 22.8.2016 11:18, Joakim Tjernlund wrote:
On Mon, 2016-08-22 at 11:13 +0200, Petr Spacek wrote:
On 22.8.2016 10:49, Ondrej Valousek wrote:
I do not think this is a good patch - systematically. Maybe better approach is to rather use gethostbyname() than gethostname(). My 2 cents.
Most importantly, this will work only for the simplest possible case where host name of the client is sub-domain of AD domain.
It will break e.g. in this scenario: AD domain = example.net. Client's hostname = myclient.branch1.example.net.
No, the patch will not touch hostname if it already have a "." in it.
Yes, but it means that we are back to to manual configuration. Even worse, if your client *is supposed* to have name "myclient.branch1.example.net." but you did not configure it explicitly, it will create DNS records for incorrect name "myclient.example.net.".
Needles to say that it is perfectly valid to have client host name like client.unrelated.example.org. (not the .org at the end!).
. at the end? That is new to me
Sorry if I confused you.
. at the end in DNS world denotes root DNS domain and thus end of fully specified DNS name. The trailing period is often omitted for brevity as a lot of software implicitly assumes that the name is fully qualified.
Still, me and RFC 1034 like to spell it explicitly so it is clear what is absolute name and what is relative name with unspecified domain part (aka "origin").
Further reading on this topic can be found on https://tools.ietf.org/html/rfc1034#page-8
Petr^2 Spacek
Having said that, I believe that SSSD should not try to be smarter in this area because it cannot do better without making wrong and surprising decisions in more complicated setups.
Petr^2 Spacek
-----Original Message----- From: Joakim Tjernlund [mailto:Joakim.Tjernlund@infinera.com] Sent: Monday, August 22, 2016 10:42 AM To: sssd-users@lists.fedorahosted.org Subject: [SSSD-users] Re: DDNS not working due to non FQDN hostname
On Mon, 2016-08-22 at 10:23 +0200, Jakub Hrozek wrote:
On Mon, Aug 22, 2016 at 08:16:36AM +0000, Ondrej Valousek wrote:
Ok, so you Jakub say that /etc/hostname should rather contain FQDN right?
No, I'm saying that gethostname()/hostname should return a FQDN. You're likely to run into all kinds of issues anyway if your system is configured with shortnames.
Seems to be different "standards", each distribution seems to have selected some variant. I think claiming that "gethostname()/hostname should return a FQDN" is THE standard will not hold, but some dists has adopted this to make life easier in some areas.
I added this short patch to sssd which will at least try to do the right thing:
--- sssd-1.13.1/src/providers/ad/ad_common.c.org 2016-08-21 17:47:09.501079617 +0200 +++ sssd-1.13.1/src/providers/ad/ad_common.c 2016-08-21 17:52:13.059669848 +0200 @@ -397,6 +397,11 @@ goto done; } hostname[HOST_NAME_MAX] = '\0';
- /* If hostname is non FQDN, add ad_domain */
- if (strchr(hostname,'.') == NULL) {
strncat(hostname, ".", HOST_NAME_MAX - 1);strncat(hostname, domain, HOST_NAME_MAX - 1);- } DEBUG(SSSDBG_CONF_SETTINGS, "Setting ad_hostname to [%s].\n", hostname); ret = dp_opt_set_string(opts->basic, AD_HOSTNAME, hostname);
I was not sure what RedHat says in terms of "best practices" here.
This is upstream list, the fact that my address ends with .redhat.com is irrelevant.
But I agree the from the admin prospective, we ideally need to have the same configuration in sssd.conf being shared by all hosts. Ondrej
On Mon, 2016-08-22 at 12:06 +0200, Petr Spacek wrote:
On 22.8.2016 11:18, Joakim Tjernlund wrote:
On Mon, 2016-08-22 at 11:13 +0200, Petr Spacek wrote:
On 22.8.2016 10:49, Ondrej Valousek wrote:
I do not think this is a good patch - systematically. Maybe better approach is to rather use gethostbyname() than gethostname(). My 2 cents.
Most importantly, this will work only for the simplest possible case where host name of the client is sub-domain of AD domain.
It will break e.g. in this scenario: AD domain = example.net. Client's hostname = myclient.branch1.example.net.
No, the patch will not touch hostname if it already have a "." in it.
Yes, but it means that we are back to to manual configuration. Even worse, if your client *is supposed* to have name "myclient.branch1.example.net." but you did not configure it explicitly, it will create DNS records for incorrect name "myclient.example.net.".
Sure, I just figured we should at least try to fix the common case. As is, it is always broken(No DNS records at all)
Anyhow, I will try a FQDN hostname here and see what happens ...
Jocke
On Mon, 2016-08-22 at 12:46 +0200, Joakim Tjernlund wrote:
On Mon, 2016-08-22 at 12:06 +0200, Petr Spacek wrote:
On 22.8.2016 11:18, Joakim Tjernlund wrote:
On Mon, 2016-08-22 at 11:13 +0200, Petr Spacek wrote:
On 22.8.2016 10:49, Ondrej Valousek wrote:
I do not think this is a good patch - systematically. Maybe better approach is to rather use gethostbyname() than gethostname(). My 2 cents.
Most importantly, this will work only for the simplest possible case where host name of the client is sub-domain of AD domain.
It will break e.g. in this scenario: AD domain = example.net. Client's hostname = myclient.branch1.example.net.
No, the patch will not touch hostname if it already have a "." in it.
Yes, but it means that we are back to to manual configuration. Even worse, if your client *is supposed* to have name "myclient.branch1.example.net." but you did not configure it explicitly, it will create DNS records for incorrect name "myclient.example.net.".
Sure, I just figured we should at least try to fix the common case. As is, it is always broken(No DNS records at all)
Anyhow, I will try a FQDN hostname here and see what happens ...
Well, that did not workout quite as I had hoped: if hostname=gentoo-labbbb.infinera.com and I join(adcli) to other domain(transmode.se) I get:
.... 15 RestrictedKrbHost/GENTOO-LABBBB@TRANSMODE.SE 15 RestrictedKrbHost/GENTOO-LABBBB@TRANSMODE.SE 15 RestrictedKrbHost/GENTOO-LABBBB@TRANSMODE.SE 15 RestrictedKrbHost/GENTOO-LABBBB@TRANSMODE.SE 15 RestrictedKrbHost/GENTOO-LABBBB@TRANSMODE.SE 15 RestrictedKrbHost/gentoo-labbbb.infinera.com.transmode.se@TRANSMODE.SE 15 RestrictedKrbHost/gentoo-labbbb.infinera.com.transmode.se@TRANSMODE.SE 15 RestrictedKrbHost/gentoo-labbbb.infinera.com.transmode.se@TRANSMODE.SE 15 RestrictedKrbHost/gentoo-labbbb.infinera.com.transmode.se@TRANSMODE.SE 15 RestrictedKrbHost/gentoo-labbbb.infinera.com.transmode.se@TRANSMODE.SE ... Notice the double domain? These are from adcli --service-name=RestrictedKrbHost DNSDOMAIN="transmode.se" REALM="TRANSMODE.SE" HOSTNAME=gentoo-labbbb
adcli -v join -D "${DNSDOMAIN}" "${DNSDOMAIN}" --host-fqdn="${HOSTNAME}"."${DNSDOMAIN}" --service-name="nfs" --service-name="RestrictedKrbHost" --service-name="cifs" --user-principal="host/${H OSTNAME}.${DNSDOMAIN}@${REALM}"
Any ideas?
Jocke
I'm joining RHEL to Active Directory and have had success updating DDNS using the following (CASE indicates the case the entry is in) 'dnsdomain' here is the domain name of my AD, ad.corp.com, and FQDNs of hosts joined to that AD look like this host.ad.corp.com. I'm not cross joining, but do have alternate domains in Kerberos. That way any host that has a dns domain different from AD it still works. Eg otherdnsdomain is other.corp.com, and the host fqdn could be host.other.corp.com. dynamic DNS doesn't exist in the other.corp.com namespace, so DDNS doesn’t work there, naturally, only AD DDNS.
On RHEL 7 ~# hostnamectl set-hostname <fqdn>
Resolv.conf Domain <dnsdomain> Search <dnsdomain>
Krb5.conf
[libdefaults] default_realm = <DNSDOMAIN> dns_lookup_realm = false dns_lookup_kdc = false forwardable = true ticket_lifetime = 24h renew_lifetime = 7d
[realms] <DNSDOMAIN> = { kdc = <dnsdomain> admin_server = <dnsdomain> }
[domain_realm] .<dnsdomain>=<DNSDOMAIN> <dnsdomain>=<DNSDOMAIN> .<otherdnsdomain>=<DNSDOMAIN> <otherdnsdomain>=<DNSDOMAIN>
~# adcli join --domain=DNSDOMAIN --login-user=my-user --verbose --service-name=host --service-name=RestrictedKrbHost --show-details
Show details on adcli shows you quite a bit, which is nice, domain controllers, what names it's using for fully qualified, domain name, computer account name, domain realm... it may help.
With that I get a keytab like this
# klist -k
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal ---- -------------------------------------------------------------------------- 3 HOST$@DNSDOMAIN 3 HOST$@DNSDOMAIN 3 HOST$@DNSDOMAIN 3 HOST$@DNSDOMAIN 3 HOST$@DNSDOMAIN 3 host/HOST@DNSDOMAIN 3 host/HOST@DNSDOMAIN 3 host/HOST@DNSDOMAIN 3 host/HOST@DNSDOMAIN 3 host/HOST@DNSDOMAIN 3 host/fqdn@DNSDOMAIN 3 host/fqdn@DNSDOMAIN 3 host/fqdn@DNSDOMAIN 3 host/fqdn@DNSDOMAIN 3 host/fqdn@DNSDOMAIN 3 RestrictedKrbHost/HOST@DNSDOMAIN 3 RestrictedKrbHost/HOST@DNSDOMAIN 3 RestrictedKrbHost/HOST@DNSDOMAIN 3 RestrictedKrbHost/HOST@DNSDOMAIN 3 RestrictedKrbHost/HOST@DNSDOMAIN 3 RestrictedKrbHost/fqdn@DNSDOMAIN 3 RestrictedKrbHost/fqdn@DNSDOMAIN 3 RestrictedKrbHost/fqdn@DNSDOMAIN 3 RestrictedKrbHost/fqdn@DNSDOMAIN 3 RestrictedKrbHost/fqdn@DNSDOMAIN
For my SPNs. That matches the computer object in AD.
In my process I do invoke kinit -k HOST$ to get a Kerberos ticket for the computer. Newer versions of adcli added support for keeping that ticket up to date, it used to expire. SSSD uses that to auth to AD DNS up update its DNS record. I'm even going to use that ticket to update a confidential attribute on the computer object to change and store the root user password on the object in AD, the same way Windows computers use LAPS for local admin account credentials. https://www.microsoft.com/en-us/download/details.aspx?id=46899 instead of a client side GPO to manage time frames and whatnot, it will be a puppet module. I digress, point being once you have the computer Kerberos ticket, you can do other stuff, not just DDNS.
It all seems to work alright for me.
Todd
-----Original Message----- From: Joakim Tjernlund [mailto:Joakim.Tjernlund@infinera.com] Sent: Monday, August 22, 2016 11:10 AM To: sssd-users@lists.fedorahosted.org Subject: [SSSD-users] Re: DDNS not working due to non FQDN hostname
On Mon, 2016-08-22 at 12:46 +0200, Joakim Tjernlund wrote:
On Mon, 2016-08-22 at 12:06 +0200, Petr Spacek wrote:
On 22.8.2016 11:18, Joakim Tjernlund wrote:
On Mon, 2016-08-22 at 11:13 +0200, Petr Spacek wrote:
On 22.8.2016 10:49, Ondrej Valousek wrote:
I do not think this is a good patch - systematically. Maybe better approach is to rather use gethostbyname() than gethostname(). My 2 cents.
Most importantly, this will work only for the simplest possible case where host name of the client is sub-domain of AD domain.
It will break e.g. in this scenario: AD domain = example.net. Client's hostname = myclient.branch1.example.net.
No, the patch will not touch hostname if it already have a "." in it.
Yes, but it means that we are back to to manual configuration. Even worse, if your client *is supposed* to have name "myclient.branch1.example.net." but you did not configure it explicitly, it will create DNS records for incorrect name "myclient.example.net.".
Sure, I just figured we should at least try to fix the common case. As is, it is always broken(No DNS records at all)
Anyhow, I will try a FQDN hostname here and see what happens ...
Well, that did not workout quite as I had hoped: if hostname=gentoo-labbbb.infinera.com and I join(adcli) to other domain(transmode.se) I get:
.... 15 RestrictedKrbHost/GENTOO-LABBBB@TRANSMODE.SE 15 RestrictedKrbHost/GENTOO-LABBBB@TRANSMODE.SE 15 RestrictedKrbHost/GENTOO-LABBBB@TRANSMODE.SE 15 RestrictedKrbHost/GENTOO-LABBBB@TRANSMODE.SE 15 RestrictedKrbHost/GENTOO-LABBBB@TRANSMODE.SE 15 RestrictedKrbHost/gentoo-labbbb.infinera.com.transmode.se@TRANSMODE.SE 15 RestrictedKrbHost/gentoo-labbbb.infinera.com.transmode.se@TRANSMODE.SE 15 RestrictedKrbHost/gentoo-labbbb.infinera.com.transmode.se@TRANSMODE.SE 15 RestrictedKrbHost/gentoo-labbbb.infinera.com.transmode.se@TRANSMODE.SE 15 RestrictedKrbHost/gentoo-labbbb.infinera.com.transmode.se@TRANSMODE.SE ... Notice the double domain? These are from adcli --service-name=RestrictedKrbHost DNSDOMAIN="transmode.se" REALM="TRANSMODE.SE" HOSTNAME=gentoo-labbbb
adcli -v join -D "${DNSDOMAIN}" "${DNSDOMAIN}" --host-fqdn="${HOSTNAME}"."${DNSDOMAIN}" --service-name="nfs" --service-name="RestrictedKrbHost" --service-name="cifs" --user-principal="host/${H OSTNAME}.${DNSDOMAIN}@${REALM}"
Any ideas?
Jocke
_______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
On Mon, 2016-08-22 at 16:59 +0000, Mote, Todd wrote:
I'm joining RHEL to Active Directory and have had success updating DDNS using the following (CASE indicates the case the entry is in) 'dnsdomain' here is the domain name of my AD, ad.corp.com, and FQDNs of hosts joined to that AD look like this host.ad.corp.com. I'm not cross joining, but do have alternate domains in Kerberos. That way any host that has a dns domain different from AD it still works. Eg otherdnsdomain is other.corp.com, and the host fqdn could be host.other.corp.com. dynamic DNS doesn't exist in the other.corp.com namespace, so DDNS doesn’t work there, naturally, only AD DDNS.
On RHEL 7 ~# hostnamectl set-hostname <fqdn>
Resolv.conf Domain <dnsdomain> Search <dnsdomain>
Krb5.conf
[libdefaults] default_realm = <DNSDOMAIN> dns_lookup_realm = false dns_lookup_kdc = false forwardable = true ticket_lifetime = 24h renew_lifetime = 7d
[realms] <DNSDOMAIN> = { kdc = <dnsdomain> admin_server = <dnsdomain> }
[domain_realm] .<dnsdomain>=<DNSDOMAIN> <dnsdomain>=<DNSDOMAIN> .<otherdnsdomain>=<DNSDOMAIN> <otherdnsdomain>=<DNSDOMAIN>
~# adcli join --domain=DNSDOMAIN --login-user=my-user --verbose --service-name=host --service- name=RestrictedKrbHost --show-details
Show details on adcli shows you quite a bit, which is nice, domain controllers, what names it's using for fully qualified, domain name, computer account name, domain realm... it may help.
Argh, I took an even closer look at my join script and found that my HOSTNAME variable was already FQDN and then I added anther domain after that, oops ....
I would like to ask one thing though, you use --service-name=host instead of --user-principal=... The difference I see in the keytab is that --user-principal just creates the host/fqdn@DNSDOMAIN while --servicename host creates both host/fqdn@DNSDOMAIN and host/HOST@DNSDOMAIN What is the significance of host/HOST@DNSDOMAIN ? Do one need it for something I have yet to discover?
Jocke
On 22.8.2016 10:16, Ondrej Valousek wrote:
Ok, so you Jakub say that /etc/hostname should rather contain FQDN right? I was not sure what RedHat says in terms of "best practices" here.
Upstream list or not, here is official Red Hat documentation about host names:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm...
Petr^2 Spacek
But I agree the from the admin prospective, we ideally need to have the same configuration in sssd.conf being shared by all hosts. Ondrej
-----Original Message----- From: Jakub Hrozek [mailto:jhrozek@redhat.com] Sent: Monday, August 22, 2016 10:07 AM To: sssd-users@lists.fedorahosted.org Subject: [SSSD-users] Re: DDNS not working due to non FQDN hostname
On Mon, Aug 22, 2016 at 06:58:07AM +0000, Joakim Tjernlund wrote:
On Mon, 2016-08-22 at 08:29 +0200, Jakub Hrozek wrote:
On Sat, Aug 20, 2016 at 03:51:31PM +0000, Joakim Tjernlund wrote:
Discovered why DDNS was not working in this ticket: https://fedorahosted.org/sssd/ticket/2565
May I suggest that if gethostname() returns a non . name, sssd should automatically add the configured SSSD domain name in sssd.conf ( [domain/domain.name] )
There is already a simple workaround of using ad_hostname, I honestly don't think we need to be overly smart in sssd.
It is not simple from an admin perspective, one needs to supply unique sssd.conf files for each computer. Actually, I think sssd is overly "dum" in this regard as it requires non standard
sssd-users@lists.fedorahosted.org
-
Jakub Hrozek -
Joakim Tjernlund -
Mote, Todd -
Ondrej Valousek -
Petr Spacek