|
Size: 1747
Comment:
|
← Revision 24 as of 2013-01-13 18:17:02 ⇥
Size: 4691
Comment: need works / cat / minor factual update
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| [[TableOfContents(2)]] == Unix == === Step 1: turn off your firewall === |
## page was renamed from TroubleshootingKerberos #pragma section-numbers off This page explains how to troubleshoot Kerberos problems. <<TableOfContents>> = Unix = == Step 1: turn off your firewall == |
| Line 10: | Line 17: |
| traceroute deleuze.hcoop.net | traceroute kerberos2.hcoop.net |
| Line 13: | Line 20: |
| The last line should say "deleuze.hcoop.net" and have NO ASTERISKS. If this is not the case, fix your firewall or your network. | The last line of output should say "kerberos2.hcoop.net" or "fritz.hcoop.net" and have NO ASTERISKS. If this is not the case, fix your firewall or your network. |
| Line 15: | Line 22: |
| === Step 2: check your krb5.conf === | == Step 2: check your krb5.conf == |
| Line 17: | Line 24: |
| Examine your `/etc/krb5.conf` (or, on MacOS, your `/Library/Preferences/edu.mit.Kerberos` file). | Examine your `/etc/krb5.conf` (or, on MacOS, your `/Library/Preferences/edu.mit.Kerberos` and `~/Library/Preferences/edu.mit.Kerberos` files if they exist (on 10.4, at least, this is /System/Library/Frameworks/Kerberos.framework/Resources/edu.mit.Kerberos, and the default configuration will ''not'' work)). |
| Line 27: | Line 34: |
| === Step 3: make sure your DNS is working === | == Step 3: make sure your DNS is working == |
| Line 35: | Line 42: |
| You should see `kerberos1.hcoop.net` in the output. | You should see `kerberosN.hcoop.net` in the output (where N is variable). |
| Line 37: | Line 44: |
| === Step 4: post to hcoop-discuss === | 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}}}. |
| Line 39: | Line 46: |
| Make sure to include: | 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. For example, DNSMASQ (no relationship to djbdns) has an option {{{filterwin2k}}} that causes it to drop these records for added security. Some network device vendors (used by OpenWrt and lots of other distros) unfortunately ship their product with this option enabled, so you will need to comment it out (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: make sure your tickets are "forwardable" == Run this command: {{{ klist -f }}} if you don't see the letter "F" after "Flags:", your tickets are not forwardable. Try {{{kinit}}} again with the {{{-f}}} flag, or adjust your {{{krb5.conf}}}. == Step 5: post to hcoop-help == Post to [[https://lists.hcoop.net/listinfo/hcoop-help|hcoop-help]]; make sure to include: |
| Line 42: | Line 63: |
| 2. The output of all the commands in steps 1 and 3. | 2. The output of all the commands in steps 1, 3, and 4. 3. The output of "[[date]]" on [[mire.hcoop.net]] at the time that you performed steps 1 and 3. |
| Line 44: | Line 66: |
| The last part is important -- we need to correlate your attempts with the error logs on deleuze, and the only way to do that is by date/time. To avoid confusion caused by time zone or clock skew, we ask that you include the time of day as reported on mire, because we know its clock is synced with deleuze's. | |
| Line 45: | Line 68: |
| === Client side firewall Setting === | == Client side firewall Setting == |
| Line 47: | Line 70: |
| 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: |
If you are using a firewall you might want to open it for UDP packets to and from at least one of our KDCs (say, kerberos2.hcoop.net) on port 88. Lines for [[http://www.netfilter.org/|iptables]] saved rules ''might'' look like the following: |
| Line 51: | Line 74: |
| [0:0] -A INPUT -s 69.90.123.67 -p udp -m udp --sport 88 --dport 1024:65535 -j ACCEPT | [0:0] -A INPUT -s 69.90.123.75 -p udp -m udp --sport 88 --dport 1024:65535 -j ACCEPT |
| Line 55: | Line 78: |
| [0:0] -A OUTPUT -d 69.90.123.67 -p udp -m udp --dport 88 --sport 1024:65535 -j ACCEPT | [0:0] -A OUTPUT -d 69.90.123.75 -p udp -m udp --dport 88 --sport 1024:65535 -j ACCEPT |
| Line 60: | Line 83: |
| == Windows == | = Windows = |
| Line 62: | Line 85: |
| Wave a dead chicken over your keyboard and pray. | In theory you would use {{{tracert}}} instead of {{{traceroute}}}, except that the Windows {{{tracert}}} doesn't use UDP packets, so it is not helpful for troubleshooting purposes. Sorry, you'll need to find a "real" traceroute. Consult the [[MemberManual/TransferringFiles/OpenAFS/Windows|OpenAFS and Windows instructions]] page of our Member Manual for further details that may prove helpful. ---- CategoryMemberManual CategoryNeedsWork |
This page explains how to troubleshoot Kerberos problems.
Contents
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 kerberos2.hcoop.net
The last line of output should say "kerberos2.hcoop.net" or "fritz.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 and ~/Library/Preferences/edu.mit.Kerberos files if they exist (on 10.4, at least, this is /System/Library/Frameworks/Kerberos.framework/Resources/edu.mit.Kerberos, and the default configuration will not work)).
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 kerberosN.hcoop.net in the output (where N is variable).
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. For example, DNSMASQ (no relationship to djbdns) has an option filterwin2k that causes it to drop these records for added security. Some network device vendors (used by OpenWrt and lots of other distros) unfortunately ship their product with this option enabled, so you will need to comment it out (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: make sure your tickets are "forwardable"
Run this command:
klist -f
if you don't see the letter "F" after "Flags:", your tickets are not forwardable. Try kinit again with the -f flag, or adjust your krb5.conf.
Step 5: post to hcoop-help
Post to hcoop-help; make sure to include:
- Your entire krb5.conf
- The output of all the commands in steps 1, 3, and 4.
The output of "date" on mire.hcoop.net at the time that you performed steps 1 and 3.
The last part is important -- we need to correlate your attempts with the error logs on deleuze, and the only way to do that is by date/time. To avoid confusion caused by time zone or clock skew, we ask that you include the time of day as reported on mire, because we know its clock is synced with deleuze's.
Client side firewall Setting
If you are using a firewall you might want to open it for UDP packets to and from at least one of our KDCs (say, kerberos2.hcoop.net) on port 88. Lines for iptables saved rules might look like the following:
[0:0] -A INPUT -s 69.90.123.75 -p udp -m udp --sport 88 --dport 1024:65535 -j ACCEPT
[0:0] -A OUTPUT -d 69.90.123.75 -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
In theory you would use tracert instead of traceroute, except that the Windows tracert doesn't use UDP packets, so it is not helpful for troubleshooting purposes. Sorry, you'll need to find a "real" traceroute. Consult the OpenAFS and Windows instructions page of our Member Manual for further details that may prove helpful.