Hello,
Can somebody confirm me the behaviour of SSSD (we're currently on version 1.8.6, but will migrate to whatever comes in Ubuntu 14.04) with regards to Kerberos DNS records?
I mean, sssd series 1.8 did not have any special handling for AD, so LDAP queries went to provided ldap_uri and Kerberos queries thanks to the dns_discover_domains are handled by the DNS SRV records for _kerberos._udp.example.com. Correct me if I'm wrong.
The DNS SRV records have a preference, or a priority option. Is this taken into account, so that lower priority server is never accessed if the higher one answers?
I am asking because or AD team implemented some "Disaster Recovery" domain controller which they only turn on for 2 hours a week, after work of course and I believe the logon time is much longer now. I don't have exact details for it, though. They claim that they cannot remove the SRV record for the "special" server as it will not replicate the AD structure to the server in such a case, so they offered to lower the priority, but I'm not sure if that's going to help.
I was also informed that the client should be actually using SRV records for the particular site, which don't contain the "special" server. Does the 1.9+ series AD backend solve this particular issue?
Best regards, Bolesław Tokarski
On Fri, Sep 06, 2013 at 02:55:48PM +0200, Bolesław Tokarski wrote:
Hello,
Can somebody confirm me the behaviour of SSSD (we're currently on version 1.8.6, but will migrate to whatever comes in Ubuntu 14.04) with regards to Kerberos DNS records?
I mean, sssd series 1.8 did not have any special handling for AD, so LDAP queries went to provided ldap_uri and Kerberos queries thanks to the dns_discover_domains are handled by the DNS SRV records for _kerberos._udp.example.com. Correct me if I'm wrong.
You're right.
The DNS SRV records have a preference, or a priority option. Is this taken into account, so that lower priority server is never accessed if the higher one answers?
Yes, we follow the RFC pretty much completely. Recently we added additional logic that also prefers servers from the DNS domain that matches the DNS domain of the client, but only on the same pririty level.
I am asking because or AD team implemented some "Disaster Recovery" domain controller which they only turn on for 2 hours a week, after work of course and I believe the logon time is much longer now. I don't have exact details for it, though. They claim that they cannot remove the SRV record for the "special" server as it will not replicate the AD structure to the server in such a case, so they offered to lower the priority, but I'm not sure if that's going to help.
I was also informed that the client should be actually using SRV records for the particular site, which don't contain the "special" server. Does the 1.9+ series AD backend solve this particular issue?
The site discovery functionality was added to 1.10
On 09/06/2013 07:10 AM, Jakub Hrozek wrote:
On Fri, Sep 06, 2013 at 02:55:48PM +0200, Bolesław Tokarski wrote:
Hello,
Can somebody confirm me the behaviour of SSSD (we're currently on version 1.8.6, but will migrate to whatever comes in Ubuntu 14.04) with regards to Kerberos DNS records?
I mean, sssd series 1.8 did not have any special handling for AD, so LDAP queries went to provided ldap_uri and Kerberos queries thanks to the dns_discover_domains are handled by the DNS SRV records for _kerberos._udp.example.com. Correct me if I'm wrong.
You're right.
The DNS SRV records have a preference, or a priority option. Is this taken into account, so that lower priority server is never accessed if the higher one answers?
Yes, we follow the RFC pretty much completely. Recently we added additional logic that also prefers servers from the DNS domain that matches the DNS domain of the client, but only on the same pririty level.
I am asking because or AD team implemented some "Disaster Recovery" domain controller which they only turn on for 2 hours a week, after work of course and I believe the logon time is much longer now. I don't have exact details for it, though. They claim that they cannot remove the SRV record for the "special" server as it will not replicate the AD structure to the server in such a case, so they offered to lower the priority, but I'm not sure if that's going to help.
I was also informed that the client should be actually using SRV records for the particular site, which don't contain the "special" server. Does the 1.9+ series AD backend solve this particular issue?
The site discovery functionality was added to 1.10 _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Is your DNS SRV resolution code packaged in such a way that it could be reusable by other programs? I was writing something up in python recently that was going to use SRV records and found almost all of the implementations to be flawed from the RFC. So a good reusable implementation would be handy.
-Erinn
On Fri, Sep 06, 2013 at 01:40:50PM -0600, Erinn Looney-Triggs wrote:
On 09/06/2013 07:10 AM, Jakub Hrozek wrote:
On Fri, Sep 06, 2013 at 02:55:48PM +0200, Bolesław Tokarski wrote:
Hello,
Can somebody confirm me the behaviour of SSSD (we're currently on version 1.8.6, but will migrate to whatever comes in Ubuntu 14.04) with regards to Kerberos DNS records?
I mean, sssd series 1.8 did not have any special handling for AD, so LDAP queries went to provided ldap_uri and Kerberos queries thanks to the dns_discover_domains are handled by the DNS SRV records for _kerberos._udp.example.com. Correct me if I'm wrong.
You're right.
The DNS SRV records have a preference, or a priority option. Is this taken into account, so that lower priority server is never accessed if the higher one answers?
Yes, we follow the RFC pretty much completely. Recently we added additional logic that also prefers servers from the DNS domain that matches the DNS domain of the client, but only on the same pririty level.
I am asking because or AD team implemented some "Disaster Recovery" domain controller which they only turn on for 2 hours a week, after work of course and I believe the logon time is much longer now. I don't have exact details for it, though. They claim that they cannot remove the SRV record for the "special" server as it will not replicate the AD structure to the server in such a case, so they offered to lower the priority, but I'm not sure if that's going to help.
I was also informed that the client should be actually using SRV records for the particular site, which don't contain the "special" server. Does the 1.9+ series AD backend solve this particular issue?
The site discovery functionality was added to 1.10 _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Is your DNS SRV resolution code packaged in such a way that it could be reusable by other programs? I was writing something up in python recently that was going to use SRV records and found almost all of the implementations to be flawed from the RFC. So a good reusable implementation would be handy.
I'm afraid the code is quite dependent on the presence of the c-ares resolver library and the libtevent event loop library. But hopefully the basic concepts should be reusable: https://git.fedorahosted.org/cgit/sssd.git/tree/src/resolv/async_resolv.c#n2...
I think that a more reusable implementation would be a nice addition to libasyncns for example.
sssd-users@lists.fedorahosted.org
-
Bolesław Tokarski -
Erinn Looney-Triggs -
Jakub Hrozek