welcome: please sign in

Diff for "MemberManual/ShellAccess/TroubleshootingKerberos"

Differences between revisions 1 and 6 (spanning 5 versions)
Revision 1 as of 2007-06-05 02:55:59
Size: 1567
Editor: AdamMegacz
Comment:
Revision 6 as of 2007-06-05 17:41:21
Size: 2970
Comment: srv debugging
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
=== Step 1: turn off your firewall [[TableOfContents(2)]]
== Unix ==
=== Step 1: turn off your firewall ===
Line 13: Line 15:
=== Step 2: check your krb5.conf === Step 2: check your krb5.conf ===
Line 25: Line 27:
=== Step 3: make sure your DNS is working === Step 3: make sure your DNS is working ===
Line 33: Line 35:
=== Step 4: post to hcoop-discuss You should see `kerberos1.hcoop.net` in the output.

If you don't see this record, one or more of the DNS servers that you're querying is probably blocking SRV requests. Figure out which name servers you're using by reading the file /etc/resolv.conf ({{{cat /etc/resolv.conf}}}) on your linux host. Query these particular name servers for the record in order to see where modifications might be necessary. You can do this by adding {{{@nameserver.example.com}}} to the end of the command, e.g. {{{dig -t SRV _kerberos._udp.hcoop.net @nameserver.example.com}}}.

You will likely find that one or more name servers you are using does not return a SRV record. If the offending name server is one that you administer, there may be an easy fix. Djbdns (used by OpenWrt and lots of other distros) need to have the line {{{filterwin2k}}} commented out or removed in order for them to pass SRV records through (see page https://dev.openwrt.org/ticket/557 for more info). Restart the device or name resolution process on the offending device for the changes to take effect. If the offending name servers that refuse to pass SRV records through aren't your own, you may have to contact the ISP that runs them, or switch to other names servers that are properly configured.

=== Step 4: post to hcoop-discuss ===
Line 37: Line 45:
1. Your entire krb5.conf
2. The output of all the commands in steps 1 and 3.
 1. Your entire krb5.conf
 2. The output of all the commands in steps 1 and 3.
Line 41: Line 49:
== Client side firewall Setting == === Client side firewall Setting ===
Line 55: Line 63:

== Windows ==

Wave a dead chicken over your keyboard and pray.

TableOfContents(2)

Unix

Step 1: turn off your firewall

Make sure any and all firewalls are disabled.

Make sure you can send UDP packets to HCOOP by typing

traceroute deleuze.hcoop.net

The last line should say "deleuze.hcoop.net" and have NO ASTERISKS. If this is not the case, fix your firewall or your network.

Step 2: check your krb5.conf

Examine your /etc/krb5.conf (or, on MacOS, your /Library/Preferences/edu.mit.Kerberos file).

Make sure that dns_lookup_kdc or dns_lookup_realm options are NOT DISABLED. They should be on-by-default, but just in case your linux distribution packager decided to be retarded and changed that, try adding

[libdefaults]
  dns_lookup_kdc   = true
  dns_lookup_realm = true

Step 3: make sure your DNS is working

Install the dig program and type

dig -t SRV _kerberos._udp.hcoop.net

You should see kerberos1.hcoop.net in the output.

If you don't see this record, one or more of the DNS servers that you're querying is probably blocking SRV requests. Figure out which name servers you're using by reading the file /etc/resolv.conf (cat /etc/resolv.conf) on your linux host. Query these particular name servers for the record in order to see where modifications might be necessary. You can do this by adding @nameserver.example.com to the end of the command, e.g. dig -t SRV _kerberos._udp.hcoop.net @nameserver.example.com.

You will likely find that one or more name servers you are using does not return a SRV record. If the offending name server is one that you administer, there may be an easy fix. Djbdns (used by OpenWrt and lots of other distros) need to have the line filterwin2k commented out or removed in order for them to pass SRV records through (see page https://dev.openwrt.org/ticket/557 for more info). Restart the device or name resolution process on the offending device for the changes to take effect. If the offending name servers that refuse to pass SRV records through aren't your own, you may have to contact the ISP that runs them, or switch to other names servers that are properly configured.

Step 4: post to hcoop-discuss

Make sure to include:

  1. Your entire krb5.conf
  2. The output of all the commands in steps 1 and 3.

Client side firewall Setting

If you are using a firewall you might want to open it for UDP packets to and from deleuze.hcoop.net:88. Lines for [http://www.netfilter.org/ iptables] saved rules might look like the following:

 [0:0] -A INPUT -s 69.90.123.67 -p udp -m udp --sport 88 --dport 1024:65535 -j ACCEPT

 [0:0] -A OUTPUT -d 69.90.123.67 -p udp -m udp --dport 88 --sport 1024:65535 -j ACCEPT

Put them before any rules that conflicts them (and before 'COMMIT' line in the saved rules file).

Windows

Wave a dead chicken over your keyboard and pray.

MemberManual/ShellAccess/TroubleshootingKerberos (last edited 2013-01-13 18:17:02 by ClintonEbadi)