[tech] Added IPv6 PTR record for Samson to fix some Kerberos issues

[Dylan Hicks]

Hi All,

Just a quick heads-up, I've added a PTR record to our DNS for Samson's IPv6 address, so that reverse lookups of this address resolve back to samson's hostname in DNS.

This should - and appears to have - resolve(d) issues with Kerberos on UCC machines like Motsugo which use IPv6 by default, as Kerberos needs to be able to figure out the correct hostname of what you're trying to access, so that it can identify the correct "principal" to use when requesting service tickets for things like AD (eg. when using `ldapsearch`). It's certainly made running `ldapsearch` on Motsugo significantly less broken for me, as I can now run queries like `ldapsearch -H 'ldap://ad.ucc.gu.uwa.edu.au/' '(cn=DylanH333)'` without having to manually enter credentials (because it uses my existing ticket-granting-ticket to get an appropriate service ticket instead), and without it running into the below error anymore:
"ldap_sasl_interactive_bind_s: Local error (-2)  
        additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Server not found in Kerberos database)"

If you want to get a list of what kerberos tickets you have in your session (eg. to see your tickets before and after running `ldapsearch`), run `klist`.

Finally, for anyone new to Wheel that wants more nitty-gritty details of how to add a PTR record for a system in our quicky DNS at UCC (and more generally new DNS records), here's what I did (after spending some time re-reverse-engineering UCC's many layers of config-file abstraction):
1. Verified that "samson.ucc.gu.uwa.edu" did have a PTR record for its IPv4 address, but not its IPv6 address, by running the following (from any UCC system):
`dig -x 130.95.13.17`
`dig -x 2405:3c00:5200:100::17`
Both of these should return a record ending in "IN PTR samson.ucc.gu.uwa.edu.au." in the answer section, but the IPv6 address didn't.
2. SSHed into our main DNS server, mooneye.ucc.asn.au, as root (you should really log in as yourself and use `sudo` instead, I'll get to why)
3. Changed directory into "/etc/bind/domains/primary"
4. Edited "ucc.machines" with a proper text editor (vim)
5. Jumped to the [samson] section, and added "6rev" under its "zones" list. This makes "zonemake.py" add an entry for it to our relevant IPv6 reverse lookup zone in DNS
6. Saved the changes ane exited vim
7. Ran ./zonemake.py
8. Followed the first two post-zonemake steps: running `rndc reload` on mooneye, and `systemctl reload apache2` on mussel
9. Realised I had to be logged in as myself to run the 3rd step (running `/usr/local/octodns/update-ucc-cloudflare.sh`), so I logged out of root at mooneye, and back in as dylanh333 at mooneye
10. Eventually figured out that I had to actually view at least one password in UCCPass, to cache my decyption password so `update-ucc-cloudflare.sh` could subsequently use it. I ran `uccpass UCC/services/DNS/cloudflare-api-certbot` to do this
11. Ran `/usr/local/octodns/update-ucc-cloudflare.sh` again, this time successfully
12. Logged back into mooneye as `root`, this time by just using `sudo -i`, changed directory to "/etc/bind/domains/primary", and commited to Git my changes to "ucc.machines", by running `git add ucc.machines` and `git commit -m "[333] ..."` (full commit message not included here).
13. Ran `git push` in an attempt to push my changes to GitLab, only for it to fail due to me not pulling any new changes down first
14. I should have done this before step 12, but ran `git pull`
15. Ran `git push` again, and this time the recent changes I made to our DNS config on Mooneye made their way up to https://gitlab.ucc.asn.au/ucc-systems/ucc-domains.git

--
Kind regards,
Dylan Hicks [333]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ucc.gu.uwa.edu.au/pipermail/tech/attachments/20220319/20a8061b/attachment.htm>