You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 20, 2023. It is now read-only.
Describe the bug
When logging into a client computer joined to a Lightwave domain controller, the login is very slow. While investigating, I see the client sending DNS queries of Type: URI for Name: _kerberos.domain.tld
Here's an example of the network activity:
05:38:28.178441 IP (tos 0x0, ttl 64, id 11855, offset 0, flags [DF], proto UDP (17), length 70) 192.168.3.120.45059 > 192.168.3.122.53: 7969+ Type256? _kerberos.WORLD.UNIVERSE. (42) 05:38:28.178640 IP (tos 0x0, ttl 64, id 45262, offset 0, flags [DF], proto UDP (17), length 70) 192.168.3.122.36804 > 10.0.100.10.53: 7969+ Type256? _kerberos.WORLD.UNIVERSE. (42) 05:38:33.174330 IP (tos 0x0, ttl 63, id 44435, offset 0, flags [none], proto UDP (17), length 81) 10.0.100.10.53 > 192.168.3.122.55392: 6637 ServFail 0/0/1 (53) 05:38:33.174357 IP (tos 0x0, ttl 63, id 44436, offset 0, flags [none], proto UDP (17), length 70) 10.0.100.10.53 > 192.168.3.122.36804: 7969 ServFail 0/0/0 (42) 05:38:33.174469 IP (tos 0x0, ttl 64, id 11184, offset 0, flags [DF], proto UDP (17), length 70) 192.168.3.122.53 > 192.168.3.120.45059: 7969 ServFail 0/0/0 (42)
In this trace, 192.168.3.120 is the client, 192.168.3.122 is the domain controller, and 10.0.100.10 is the upstream DNS server the domain contoller uses as DNS Forwarder.
It appears to show a dns query for a type 256 (URI) query for "_kerberos.world.universe" from client to server. the server is unable to answer, so sends it up stream to forwarder. Forwarder is unable to answer (now we have a loop), so returns SERVFAIL which the domain controller then passes back to the client.
Impact
Low - Not really in your way but annoyance
Medium - Can be worked around
High - Blocker
Expected behavior
I would expect that vmdns could answer Type 256 / URI queries, or at the very least, that vmdns returns NXDOMAIN for a resource record query for a name in a domain for which it is authoritative does not exist. Returning NXDOMAIN from the domain controller would allow the client to continue and the login to complete much faster.
Observed behavior
vmdns forwards the query to forwarder. the forwarder is configured to forward queries for the "world.universe" domain to the domain controllers, so now there is a query loop. Therefore, the upstream forwarder returns SERVFAIL, which the domain controller forwards back to the originating client.
To Reproduce
Steps to reproduce the behavior:
set up lightwave domain controller, pretty much default configuration
join a client to the domain
3.create a user account in the domain
enable pam and nsswitch on the client using domain-join configure --enable commands
attempt to ssh login to the client with the test user account
Edit to add... This particular problem can be worked around, to a certain degree, but adding iptables rules that reject DNS queries of type 256. for example,
iptables -A INPUT -p udp --dport 53 -m string --hex-string "|09|_kerberos|05|WORLD|08|UNIVERSE|000100|" --algo bm -j REJECT
(also add ip6tables rules if you use ip6)
This reduces login time from about 45 seconds to about 5 seconds.
Describe the bug
When logging into a client computer joined to a Lightwave domain controller, the login is very slow. While investigating, I see the client sending DNS queries of Type: URI for Name: _kerberos.domain.tld
Here's an example of the network activity:
05:38:28.178441 IP (tos 0x0, ttl 64, id 11855, offset 0, flags [DF], proto UDP (17), length 70) 192.168.3.120.45059 > 192.168.3.122.53: 7969+ Type256? _kerberos.WORLD.UNIVERSE. (42) 05:38:28.178640 IP (tos 0x0, ttl 64, id 45262, offset 0, flags [DF], proto UDP (17), length 70) 192.168.3.122.36804 > 10.0.100.10.53: 7969+ Type256? _kerberos.WORLD.UNIVERSE. (42) 05:38:33.174330 IP (tos 0x0, ttl 63, id 44435, offset 0, flags [none], proto UDP (17), length 81) 10.0.100.10.53 > 192.168.3.122.55392: 6637 ServFail 0/0/1 (53) 05:38:33.174357 IP (tos 0x0, ttl 63, id 44436, offset 0, flags [none], proto UDP (17), length 70) 10.0.100.10.53 > 192.168.3.122.36804: 7969 ServFail 0/0/0 (42) 05:38:33.174469 IP (tos 0x0, ttl 64, id 11184, offset 0, flags [DF], proto UDP (17), length 70) 192.168.3.122.53 > 192.168.3.120.45059: 7969 ServFail 0/0/0 (42)
In this trace, 192.168.3.120 is the client, 192.168.3.122 is the domain controller, and 10.0.100.10 is the upstream DNS server the domain contoller uses as DNS Forwarder.
It appears to show a dns query for a type 256 (URI) query for "_kerberos.world.universe" from client to server. the server is unable to answer, so sends it up stream to forwarder. Forwarder is unable to answer (now we have a loop), so returns SERVFAIL which the domain controller then passes back to the client.
Impact
Expected behavior
I would expect that vmdns could answer Type 256 / URI queries, or at the very least, that vmdns returns NXDOMAIN for a resource record query for a name in a domain for which it is authoritative does not exist. Returning NXDOMAIN from the domain controller would allow the client to continue and the login to complete much faster.
Observed behavior
vmdns forwards the query to forwarder. the forwarder is configured to forward queries for the "world.universe" domain to the domain controllers, so now there is a query loop. Therefore, the upstream forwarder returns SERVFAIL, which the domain controller forwards back to the originating client.
To Reproduce
Steps to reproduce the behavior:
3.create a user account in the domain
domain-join configure --enable
commandsduring login, capture packets to see above.
Environment:
OS: photon 2.0, PHOTON_BUILD_NUMBER=0922243
Lightwave Version:
lightwave-client-libs-1.3.1.7-1.ph2.x86_64 lightwave-1.3.1.7-1.ph2.x86_64 lightwave-client-1.3.1.7-1.ph2.x86_64
Likewise version:
likewise-open-6.2.11.4-4.ph2.x86_64
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: