howto://add the Telnet client to Windows 10

Just a quick reminder to myself on how to enable the Telnet Client in Windows 10, since I always seem to forget.

  1. Open an administrative command prompt.
  2. Run this command
    dism /online /enable-feature /featurename:telnetclient
  3. Done. It will be immediately available, even in existing, non-admin command prompts you already have open.

If you want to test it out, try this! telnet://towel.blinkenlights.nl/

howto://disable hibernation in Windows

In case you don’t ever plan to have your computer hibernate, and would like to buy back the disk space wasted reserved by hiberfil.sys, it’s pretty simple to fix this.

  1. Open an administrative command prompt
  2. Run this command
    powercfg /hibernate off
  3. Profit 🙂

howto://set a Windows Server 2016 Hyper-V host to use SNTP for time sync

TL;DR
set your server to sync to NTP by running these commands.

w32tm /config /syncfromflags:MANUAL /manualpeerlist:pool.ntp.org /reliable:yes /update

net stop w32time && net start w32time

So I’m in the process of (re)setting up my lab, using a pair of multi-proc servers running Hyper-V to host my VMs. These will be member servers, which would normally get their time from a PDC in their domain. Of course, DCs normally need to get their time from a reliable time source, but as VMs, mine would get their time from the host servers on which they run. I could have changed the DCs of course, but instead opted to make those physical systems more reliable. That’s what this post is all about. Continue reading “howto://set a Windows Server 2016 Hyper-V host to use SNTP for time sync”

kerberos response codes

code message meaning
0x6 KDC_ERR_C_PRINCIPAL_UNKNOWN: Client not found in Kerberos
database
0x7 KDC_ERR_S_PRINCIPAL_UNKNOWN: Server not found in Kerberos
database
0x8 KDC_ERR_PRINCIPAL_NOT_UNIQUE: Multiple principal entries in
database
0xA KDC_ERR_CANNOT_POSTDATE: Ticket not eligible for postdating
0xC KDC_ERR_POLICY: KDC policy rejects request
0xD KDC_ERR_BADOPTION: KDC cannot accommodate
requested option
0xE KDC_ERR_ETYPE_NOTSUPP: KDC has no support for
encryption type
0xF KDC_ERR_SUMTYPE_NOSUPP: KDC has no support for
checksum type
0x12 KDC_ERR_CLIENT_REVOKED: Clients credentials have
been revoked
0x17 KDC_ERR_KEY_EXPIRED: Password has expired change
password to reset
0x19 KDC_ERR_PREAUTH_REQUIRED: Additional pre-authentication
required
0x1B KDC_ERR_MUST_USE_USER2USER: principal valid for
user2user only
0x1C KDC_ERR_PATH_NOT_ACCEPTED: KDC Policy rejects transited
path
0x1D KDC_ERR_SVC_UNAVAILABLE: A service is not available
0x1F KRB_AP_ERR_BAD_INTEGRITY: Integrity check on decrypted
field failed
0x20 KRB_AP_ERR_TKT_EXPIRED: Ticket expired
0x21 KRB_AP_ERR_TKT_NYV: Ticket not yet valid
0x22 KRB_AP_ERR_REPEAT: Request is a replay
0x23 KRB_AP_ERR_NOT_US: The ticket isn’t for us
0x24 KRB_AP_ERR_BADMATCH: Ticket and authenticator
don’t match
0x25 KRB_AP_ERR_SKEW: Clock skew too great
0x29 KRB_AP_ERR_MODIFIED: Message stream modified
0x34 KRB_ERR_RESPONSE_TOO_BIG: Response too big for UDP,
retry with TCP
0x3C KRB_ERR_GENERIC: Generic error

im in ur datastreams, fixup’in’ ur protokols

So the other day, I found myself involved in two different attempts to fix the same problem, which had apparently been an issue for over a year for these guys. They both wanted to use FTP to move files from a host on one segment, to an FTP server on another segment. Sounds simple, right? Well if it was, I wouldn’t be writing this article, would I?

 

Situation:
-Two hosts need to communicate with one another using FTP
-across a firewall
-NAT is in place
-the FTP server is using the non-standard port 1959

First, a review of FTP is in order. The current RFC for FTP is 959. Note that FTP commands embed network addressing within the Application layer of the protocol each time a PORT command (amongst others) is issued. The client embeds its IP address in the command, as so.

PORT 010,001,001,024,016,002

Note that the address is represented as padded, comma separated octets. The FTP server uses that information to open a connection back to the client for the data transfer. In this instance, the FTP client is on one network segment, the FTP server is on another, and there is a firewall between them. In the stream, the client’s network traffic is translated by the firewall so that it appears to be at the desired address, even though it is located on another network. This is transparent to both hosts, and to the user. Unfortunately, the FTP server cannot access the FTP client at the real ip.addr (10.1.1.24) because the NAT represents the FTP client as having ip.addr 10.3.1.24.

While Network Address Translation is frequently used, there are limitations to what it can do. The normal NAT process can only alter ip.addrs at the Network layer, and port numbers at the Transport layer. For many protocols, this is sufficient to permit the use of NAT, and to do so in a way that is transparent to the user, the hosts, and the application protocol(s) in use. There are however certain protocols that embed the ip.addr and/or port within the Application layer, as FTP does in its port commands. NAT does not inspect the Application layer, so when the destination host receives traffic with one set of addressing at the Network and/or Transport layer, and another set of addressing at the Application layer, problems will occur. This will break RPC traffic completely. For other traffic, there is the fixup command.

PIX firewalls have a feature called fixup which is enabled by default for many protocols on default (IANA assigned) ports. In the firewall configuration, this command is present.

fixup protocol ftp 21

Fixup does several things, but in this case we are most interested in its ability to basically perform NAT functions at the Application layer. Fixup can substitute the NAT address for the real one in the PORT commands transparently, neatly fixing the problem. Of course, if the FTP service had been bound to the default port, this would not have been a problem to begin with. The necessary action on the firewall is to add this command.

fixup protocol ftp 1959

Problem solved.

Summary:

  1. Whenever possible, stick with default ports.
  2. When using NAT, evaluate the protocols in use for whether or not they play nicely with NAT.
  3. Use the fixup protocol command to inspect the application layer and make relevant corrections.
  4. Remember that not all protocols can be fixed up!

here endeth the lesson 😉