The original Japanese version is available here.
I used to travel to various places for work, but since the outbreak of COVID-19, I haven’t been able to go abroad. The government seems to be actively restarting inbound tourism, so outbound travel may also return to normal soon. In the past, when it came to entertainment at foreign hotels, Japanese TV channels were the only option. However, since just before the COVID-19 pandemic, I have often encountered situations where guests use streaming services such as Netflix on their TV. While it is a good idea to be able to watch video content anytime, anywhere, there are issues for foreign visitors who want to use Japanese services in a Japanese language environment. For example, if you try to use a Japanese service comfortably in Japanese environment, you will be unable to connect from overseas and receive an error message. I’m not sure if it’s a copyright or broadcasting rights issue, but you will be rejected. Of course, it is not necessary for those who can relax by watching local Danish talk shows in Danish, but for people like me who are Japanese at heart, using VPN is essential. I have to connect from Denmark to my company’s Japanese VPN gateway and watch the usual services via Japan’s firewall. From the content provider’s perspective, there is no reason to reject the connection because it appears to be from a Japanese IP address. With this method, I can watch domestic services as usual.
In the previous time, we set up and tested only the primary KDC. As a result, you should have the following files in the /var/heimdal directory, and the location of the KDC can be obtained from the KDC’s service record in DNS.
This time, we will set up a backup for the KDC and replicate the database between the primary and secondary. First, we will confirm that the /var/heimdal directory on the secondary host ‘package’ is empty.
To operate as a KDC, initialize the database. Of course, it must behave exactly the same as the primary, so use the exact same realm and options.
To function as a backup, it’s necessary to use the same master key. So, copy the primary’s /var/heimdal/m-key file in a safe manner. Here is an example: create a directory that only I can access and copy the file there. To avoid copying the file permissions, create a new file and copy only the contents.
And then, use SFTP or similar to copy the file on the server package, and make sure it can only be read and written by root.
We now have a clean KDC file on the server package. Next, we will prepare for replication. The current keytab file contains the host principal.
If you look at the manual for iprop, which we will use for replication, it says to use the principal iprop/host@realm (see man iprop). So, we will create those principals for both the primary and backup.
The next step is to import the created principals into the keytab file. First, for the primary server dhcp.
And then, for the backup server package.
Finally, we will follow the steps to change the logging related to syslog from the files in the /var/heimdal directory. We can change the output destination of the logs in the same way as the primary.
We will define the necessary variables using sysrc command so that the required services start at system boot automatically. According to the iprop manual, ipropd_master should start even without arguments. However, the /var/heimdal/slaves file must contain the principal of the backup servers. If you write the backup principal to the slaves file and run the startup script without setting the ipropd_master_slaves variable, it will not run as this variable needs to be set. Therefore, we define the ipropd_master_slaves variable with the information for the backup. This variable’s definition should be set to the principal of the backup, as it will be copied to the /var/heimdal/slaves file each time it starts. Here’s an example of what it should look like.
Check the /var/heimdal directory. You should see three new files beginning with ‘s’. The slaves file contains the principal for the backup KDC. The slaves-stats file records when the last connection was made from backups. At this point, there should be no timestamp in the file as there has been no connection from the backup yet.
We will then configure the backup server to start the KDC automatically and start the KDC. Then, we start the iprop slave server. According to the man page for iprop, it takes the primary server’s hostname as an argument, so we specify the hostname of the primary server as a variable in the /etc/rc.conf file.
With this, the setup should be complete, so let’s try starting the backup server. If the connection is successful, this type of log will be recorded. The numbers increase sequentially, which means they increase up to the version of the KDC database on the primary server and wait until the next change is made.
Now that redundancy should be ensured, let’s check if it works. First, with everything running, try running kinit on the server krb5. Of course, you should be able to get a ticket from the primary server.
Next, let’s simulate a failure. First, stop the primary and backup KDCs to see what happens when the KDC is completely unavailable.
The next step is to discard the existing tickets and try to obtain new ones in this state.
We can see from the error message that the KDC is not available. Let’s try starting only the KDC on the backup server package. The KDC on the server dhcp package will remain stopped.
If you run kinit in this state, you should be able to get a ticket from the backup server.
The ticket obtained in this way should be valid on other servers just like the ticket obtained from the primary server. Let’s check with ssh.
In this experiment, we only tested read access on the backup server and did not run kadmind or kpasswdd. Their location can be known through service records by setting up DNS appropriately. So, it may be possible to maintain redundancy for these services as well. There was no explanation about this in the man page for iprop. If this is possible, the biggest unknown is whether the updated information on the backup during the primary’s downtime can be updated from slave to master in iprop. By the way, Windows Active Directory replication is bidirectional, so changes made to any KDC can be used by all KDCs. I do not have information at the moment, but if I find out, I will introduce it in a separate article.
Well, another problem I had was that when I was on a business trip to China, I tried to investigate Japanese administrative services on a personal level, but I couldn’t connect from China, no matter how hard I tried 🙂 So, I had to use a VPN connection to access from a Japanese IP address and find out what I needed. Speaking of VPNs, they are often thought to be necessary when using internal resources from outside the company, but they are also very useful when using external resources from outside the company. I remember almost always having it on when I was overseas. As inbound acceptance resumes and outbound traffic increases, it is likely that individuals will need VPNs as well. Some companies may be reluctant to use their own firewalls or not have VPNs enabled. It is unlikely that most organizations will provide VPNs to their wives or children for access to the company’s firewall. Especially recently, due to the Russia-Ukraine war, some companies have changed their firewall settings to not accept IP connections from explicitly dangerous countries, and I think this trend is accelerating.
When I returned from overseas and was at the domestic airport in Japan, I connected to the Free WiFi to check the time for my connecting train while drinking Starbucks. Do you know that Free WiFi is also full of dangers? Due to my job, I know that it is easy to obtain information illegally by deceiving the SSID. If you see an SSID like KIX-Free-WiFi on your iPhone when you arrive at Kansai Airport, wouldn’t you use it? Most of this Free WiFi is not encrypted, and if someone can view the packets, all the information on the network will be exposed. Of course, I would never do such a thing, but not everyone with knowledge of networks is a good person.
In a situation where the importance of cybersecurity is being emphasized by both government and private sector, it has become essential for us ordinary people to be knowledgeable about it. It’s like being a tourist in a war zone where bullets are flying and you have neither a helmet nor a bulletproof vest. Do you understand? You never know when a bullet might hit you. And to make matters worse, unlike normal bullets that cause bleeding and pain, these can pass through you unnoticed and weeks later, you might receive a huge amount of bills and die instantly. Or the amount of blood being drawn each month is so small that you might allow the parasite to continue living inside you without even realizing it. There is no reason to allow such situations, and it is necessary to encrypt all network connections to protect us.
One widely used method to encrypt connections with servers is HTTPS, as seen on online shopping sites, where the URL starts with https://. However, keep in mind that this only encrypts communications with that site. Everything else is essentially naked. VPN is the solution that will dress the naked emperor. Network administrators can create their VPNs, but it can be challenging for the average person. A better option is to use a commercial VPN service. VPN services are available worldwide, but for VPN usage, it is necessary to use a domestic service. Even if you use a VPN service in China while in Denmark, you may encounter issues such as being unable to access Facebook or perform Google searches. Therefore, the best practice is to use a VPN service in your home country. I once lost all the data on my iPhone because I did not back it up to iCloud. I had used an incorrect PIN accidentally, and as a result, all my information disappeared. I had to gather scattered information and spend many days recovering it, all because I wanted to save a few hundred yen on storage fees. Fortunately, I was able to recover my passwords by using Google Chrome’s synchronization feature, but I would have been out of luck if I hadn’t had that option. VPN services are not that expensive, and it is better to be safe than sorry.
Advertisement below
コメント