DEV Community: Shoban Chiddarth

On Age Verification

Shoban Chiddarth — Wed, 27 May 2026 02:09:33 +0000

Introduction

If you have been living under a rock (good for you), several states in America and the country of Brazil have introduced a new law that forces operating system developers to implement "age attestation" of the user, you will have to provide your age and then an age bracket will be stored which will be broadcast to every app and service you use in your operating system, and app stores (apt sources) are required to acknowledge this and filter software based on age, and assume lowest age bracket if the age is not given.

Age verification tracker: https://github.com/BryanLunduke/DoesItAgeVerify/ (fork that maintains links to original developer statements: https://github.com/softcookiepp/DoesItAgeVerify). This has all information regarding it.

In this blog post, I will share my opinions on it and explain why it is impossible to enforce these laws as well as impossible to comply with these laws. It is actually illegal to follow the US law according to the US law, I will explain below.

Facebook

Meta is behind this. Meta is pulling the strings and getting the law makers to pass such laws. Here is the proof:

Since Mark Zuckerberg is the mastermind behind all these, and due to how trustworthy he is

it is logical to expect the very next step from the lawmakers is to make you upload your government issued ID photo to the operating system before setting up the account. So that every action you take in the computer, every local text file you save, every message you send in end to end encrypted messaging apps, every local file you save, every email you send by gpg encrypting it, every social media post you make from an anonymous account, can be pinpointed to who exactly you are and your location, so that the government can keep a social credit score for people and arrest anyone that disagrees with the government and enforce a totalitarian regime like 1984 or present day China.

This is their plan. It is a slippery slope. It is Facebook after all. Now they push for "age attestation" which is "just a minor thing" according to some people and after it is accepted as a "usual thing" they push for a little more like precise age numbers and then you end up with ID.

Linux

The law keeps definitions of "Operating System", "User", "Account" as vague as possible to enforce it into as many places as possible. And anyone with a functioning mind would think the entire Linux community, built around privacy and security, would be vehemently opposed to this law and refuse to follow it and try as much as possible to get this law deleted. But that is where you are wrong. At least most of the people, the users, are against the law.

Ubuntu will comply and Debian will help downstream distros implement it (it is in the tracker). And Arch Linux, an OS literally made to give you full control over your computer, says opposing age verification is violation of code of conduct. There is more on Lunduke's (the only journalist covering these kinds of tech news you wouldn't find on mainstream media) channel. And also systemd, an init process that is supposed to start the system, has a module called userdb and it previously stored a lot of PII like name and email and now it stores user birthdate to comply with the law so that xdg-desktop-portal can use it as a reference to implement the age attestation (PR link). And also linux reddit censors age verification related posts.

systemd

When I started out with Linux I did not understand the hate around systemd. I thought it was just a normal piece of software with unnecessary drama and also it worked kinda fine like it took care of things and was programmable so I didn't understand why people did not like it and moved away from it. But now I do. It is owned by RedHat and is extremely bloated and does things it is not required to do for no reason at all. I hated it more and more as I was going deeper into computers and Linux. It has a local DNS middleman server for god knows why the system needs another middleman when I run my own DNS server. I had to configure a lot of things to make sure the systemd-resolved stays shut down. An init process storing user PII, and modifying it to comply with privacy invasive freedom restricting laws, and resolving DNS, managing IP addresses of network interfaces (systemd-networkd) is too much for an init process, it increases the attack surface and adds too much unnecessary bloat to the system.

Distro hopping

The only developers who oppose this law are listed in the tracker I shared above. I personally use Linux Mint and Mint is currently not affected by systemd storing user birthdate because Mint does not ship with systemd-userdbd (Source) so even if upstream software like xdg-desktop-portal implement it, it will have no point of reference for the user birthdate. However, that is only true for the current state of the OS (22.3 zena). The developers of Mint have not made any public statements regarding age verification and assuming the worst, if they implement age verification by shipping the next update with systemd-userdbd or in some other way, I can simply refuse the dist upgrade. Also I am currently refusing all updates to systemd related packages using this command.

sudo apt-mark hold *systemd*

So the dist upgrades have been refused and systemd related packages have been held back from updating, meaning I have a lot of time to switch to an operating system that publicly opposes age verification as well as does not have systemd. I am choosing to go with Artix (Arch without systemd) for my laptop as it gives full control over my computer, and Devuan (Debian without systemd) for my server for stability. If you are using a Linux distro that is going to implement age verification like Ubuntu or Fedora consult the above tracker to make a decision on the OS that fits your needs and opposes age verification and does not have systemd and switch to it as quick as possible. If you are using Windows switch to Linux, it is a corporate controlled proprietary OS and they already do a lot of spying on you and also Zuckerberg, Bill Gates are all a part of the Epstein class and they are all in this together.

Why is it impossible to enforce this law?

Obviously, Linux is open source and if the OS adds age verification, someone will just fork it and create a "libre" version that doesn't have it. And good luck to government jarheads trying to arrest everyone, you won't have enough room in prison.

Why is it impossible to comply with this law?

Even if every single person in America is willing to comply with this law, it is literally impossible. The law is very very vague about the definitions of an Operating System, an Account, and a User. So almost everything that is technically a "computer" falls into this law. And almost everything that is a computer (that probably runs linux) includes your laptop and desktop and servers (obviously), your smart TV, your smart watch, your calculator (probably), your "smart" washing machine, fridge, dishwasher and other smart devices, your robot vacuum cleaner, your router, raspberry pis that are part of iot devices, any and all forms of iot devices, your CCTV cameras, your baby and dog monitor, believe it or not switches (the layer 2 network devices) are also technically a computer because they have an OS (Cisco IOS), Nintendo Switch console, the gas station pump, your car probably, the bar code scanner at Walmart, traffic signals, public surveillance cameras, your smoke detector, and a lot of things, the list is so long that it cannot be fit in this blog post.

If everyone in America wanted to comply with the law by entering their age into all "computers" they own, the entire internet will break, several people will die, and a lot of things will be broken. So many things in this world are computers.

Right to Repair

Also it is illegal to comply with this law. DMCA Law in the US states that you are not allowed to use technical skills to circumvent DRM on a device (you are legally not allowed to modify a device you own and paid money for) or to "hack" it to run whatever software you want. You could face 5 years in jail or $500,000 fine for changing the electric circuits of a physical device you purchased with money and own in your hand.

Nintendo used this law to sue people breaking into Nintendo Switch (the gaming console) to run custom software. BMW implemented subscription based heated seat, using electricity from the battery of the car that you paid for, generated by the fuel you paid for, which costs the company $0 to produce some heat yet they charge users monthly for it. And it is backed by the law, if you circumvent it to have unlimited heated seat then you go to jail. And Tesla implemented a pay walled battery, you have to pay money to use 100% of the battery that you own. BMW is a horrible company by the way they patented BMW screws that can only be purchased from their vendors to make sure you always come to them for repairs and don't repair on your own, that is a completely different story but America is slowly becoming this corpo owned hell hole.
Sources:

Coming back to what I was saying, it is illegal to open up your robot vacuum cleaner and flash a custom operating system into it, in the place where the current linux distro of it is running, by somehow wiring it up with a keyboard mouse and display. So you are not allowed to do it or you face prison. But the age verification law says you are required to enter your age into all "computers" you own and the only way to enter it into your robot vacuum cleaner is to circumvent its DRM by breaking it open, which is illegal. (this applies to not just robot vacuum cleaners).

America has finally made it. It is illegal to follow the law. Welcome to land of the free baby, where you are legally not allowed to modify devices you paid money to own and cannot have anonymity and privacy.

Louis Rossmann (the man behind the clippy movement) has been shouting about the "Right to Repair" for a very long time. Please pay attention to that one: https://www.youtube.com/@rossmanngroup/videos and https://consumerrights.wiki/w/Main_Page

Cloud is up there above us

And almost nobody on the internet has covered the cloud side of things related to age verification.

Docker containers are also technically a computer since it is an OS (alpine mostly). Are people required to enter their age inside docker containers too? Are you only required to enter your age when pushing a docker container to the internet or whenever creating it like dev or testing? What about Virtual Machines? Amazon Web Services offer an OS called "Amazon Linux" so they are also operating system developers. So by law they are required to implement age attestation in their OS, I am not sure what they are gonna do about it.

AWS is the biggest cloud provider where majority of production infrastructure lives. Since the law requires every "user" that has an "account" on every "computer" to enter their age, will Jeff Bezos be required to enter his age into every single EC2 instance created in American regions?

Even if he is willing to, let's assume it takes Jeff Bezos 3 seconds to enter his age into 1 EC2 instance (type 2 numbers + enter key + window switching). So that is 86,400/3=28,800. He will be entering his age into 28,800 EC2 instances per day which is a frighteningly low amount of EC2 instances compared to how much actually exist and is being created every day, assuming he is willing to work 24 hours.

Most of the real production infra does not have EC2 instances manually created and provisioned from the console, they are all automated using tools like Terraform. And 28,800 EC2 instances does not count the several internal "technically a computer" servers that are used for things like lambda, ECS, Fargate, EKS and there is still a ton more including other cloud providers, on prem data centers many companies use, and also the on prem network devices (like switches and routers I mentioned above). Now you see why the entire internet will break, it is impossible for the owner of the "computer" to enter their age into every "computer" they own due to the laws of physics.

The law is extremely vague about the definitions either because lawmakers are stupid and think cloud means where we get the rain from or they are evil and want to strip away as much people's rights as possible and I don't know which is worse or it could be both.

Why should someone in India (me, and you, even if you are not in India) care about some American law?

Brazil is a country that is not America yet Facebook pulled strings and got the law passed over there. India is next. Indian government isn't exactly pro consumer rights or pro privacy, law requires VPN services to store logs and share them with the government, that is why ProtonVPN moved away from India. And there were talks about the government banning entire Proton suite from India because some idiot sent a fake bomb threat somewhere using proton email address and they were not able to find him. Call me paranoid but I think the someone is the government making up reasons to ban proton mail.

And even if the law hypothetically never comes to India, if I am using Ubuntu (thankfully I am not) and Ubuntu pushes an update on the day the law takes effect forcing me to enter my age or else lock my drive, I will have no choice but to either comply with the law (which is bad and is a slippery slope like I said above) or to mount the hard drive, somewhere else, copy the files, and reinstall another OS that doesn't have age verification which will be tedious to do after the law has been implemented, hopping to another distro now is easy. This is the same as disaster recovery in Cloud Computing, we don't wait until disaster happens to recover resources, we plan in advance and provision multi AZ or multi region so if disaster affects on AZ or an entire country we would still have other areas up and running.

Here's what you are gonna do

Get as many normies to switch to Linux
Tell everyone you know about age verification
Increase awareness about the importance of privacy, anonymity, security, and right to repair
If someone already uses Linux, get them to switch to an OS that doesn't support age verification (see tracker)

Documenting my Physical Home lab in Packet Tracer

Shoban Chiddarth — Tue, 05 May 2026 17:09:00 +0000

Repo link: github.com/ShobanChiddarth/physical-homelab-in-packet-tracer

Introduction

I recently finished my 3rd year end sem exams and I am in my summer holidays. I am preparing for the CCNA certification so I decided to recreate my physical home lab in Cisco Packet Tracer.

To download the packet tracer lab file you can visit the GitHub repo linked in the top of this post and look at the README.

Technical Details

Setup

I used a WRT300N router to simulate the Tenda AC6 router, and a 1941 (non wireless) router to simulate the Jio Fiber router. I did not need to connect any wireless devices to the Jio router in this packet tracer lab and also in Packet tracer connecting the WAN port (Internet port) of a wireless router to the LAN port of another wireless router wouldn't work like in real life, it refuses to form a connection. So I went with static IPs for the Jio Router's LAN port and Tenda Router's WAN port.

Devices inside Tenda router's LAN

As shown in the previous entries of this series, there is a ThinkCenter M81 (represented by Server PT) connected through ethernet to the Tenda router, in which HTTP and DNS services have been enabled (Pi-hole). And my laptop and my smartphone are connected over Wi-Fi to the Tenda router.

Devices outside Tenda router's LAN (inside Jio router's LAN)

We will not be worrying about this part as I do not control the Jio router and guests and other family members will be using it. There are mobile phones and a TV connected to it. There was a smart vaccum cleaner connected to it long ago like in the same Jio LAN without any isolation and it stopped working but if I was in charge of managing the network I would have set up proper isolation for IOT devices like this one by putting them on a separate VLAN, setting up guest network and blocking them from communicating with other devices using ACLs.

Internet Access

Real internet is not possible inside Cisco Packet tracer so assume the cloud up above is the real internet.

IP Configuration

IP configuration is the exact same as my lab in real life

Jio LAN = 192.168.29.1/24
Tenda WAN = DHCP
Tenda LAN = 192.168.1.1/24
ThinkCenter M81 (Pi-hole) = 192.168.1.2
My Laptop = DHCP
My Phone = DHCP

Screenshots

Full Lab

Pi-hole DNS records

Pinging ThinkCenter M81 from My Laptop

Accessing Pi-hole dashboard from My Laptop

I edited the default index.html in HTTP server a little bit, this is not an actual computer so installing Pi-hole is not possible. The DNS resolution works that is what is important.

Accessing Pi-hole dashboard from My Phone

Conclusion

Therefore I successfully created a simulation of my real home lab inside Packet Tracer. I am currently preparing for CCNA certification and this packet tracer lab has helped me map a network whose behaviour I already know onto Packet Tracer's environment. When you build a network from scratch in a simulator, you have no reference point, but when you recreate something you physically own, you immediately notice where the simulator behaves differently from reality and understand its limitations, and that gap is where the actual learning happens.

AWS Terraform infrastructure for a FastAPI+PostgreSQL backend

Shoban Chiddarth — Mon, 23 Mar 2026 14:47:31 +0000

Introduction

This blog post showcases the AWS infrastructure written in Terraform for the backend of alumni-connect, a MVP of a college project written in FastAPI with a PostgreSQL database.

The terraform repo: https://github.com/ShobanChiddarth/alumni-connect-terraform
The backend repo: https://github.com/ShobanChiddarth/alumni-connect-backend

Architecture

VPC Design

Since this is an MVP, I went with the absolute minimal for everything. 1 VPC exists on ap-south-1. It has an internet gateway. Frontend is hosted in netlify, so API requests as well as management traffic (SSH) will enter through the internet gateway.

Subnet Design

There are 4 subnets in total.

A public subnet to handle management traffic (ap-south-1a)
2 private subnets for backend and database EC2 instances (ap-south-1a)
Another public subnet to satisfy AWS's hard requirement of multi AZ for load balancers (ap-south-1b)

The management subnet:

Contains the bastion EC2
Contains a NAT gateway for EC2 instances in the private subnet to reach the internet

Load Balancer

The backend EC2 has no public IP and sits in a private subnet. Its security group only accepts port 8000 from the ALB security group - there is no direct path from the internet to the backend. The ALB is the only entry point.

listens on port 80 for HTTP traffic from the public internet
spans across ap-south-1a (management subnet) and ap-south-1b (empty subnet) - AWS requires an internet-facing ALB to span at least 2 AZs
forwards the traffic from the internet to port 8000 in the backend EC2

Security Groups Design

SSH traffic from the internet is allowed only to the bastion EC2
SSH traffic to the backend and database EC2s are allowed only from the bastion EC2
HTTP traffic from the internet is allowed only to the load balancer
HTTP traffic to the backend is allowed only from the load balancer
Database traffic (port 5432) to the database EC2 is allowed only from the backend EC2

SSH Keys

Bastion EC2's SSH private key stays on the local computer of the person deploying this
Other EC2s SSH private key stays in the bastion

EC2 instances

Backend EC2 is set to pull and run docker image shobanchiddarth/alumni-connect-backend:0.0.2
Database EC2 is set to pull and run docker image postgres:16

NAT Gateway Cost Problem

I wrote a LinkedIn post about this. Click here to view it.

If you are not able to see it, here are the contents of the post:

I recently faced a problem with making EC2 instances communicate with the internet while deploying a FastAPI+Postgres backend architecture on AWS using Terraform. NAT Gateways exist to solve this - a NAT gateway can be placed in a public subnet and traffic can be routed through it.

But NAT Gateways are costly. ~$0.045/hr just to exist, plus data transfer charges.

The solution I used: keep the NAT gateway in the Terraform code, but destroy it immediately after deployment. Private instances lose internet access after packages are updated, Docker images are pulled, and containers are running.

terraform destroy -target=aws_nat_gateway.alumni-nat-gw -target=aws_eip.nat-gateway-elastic-ip

I also tried a NAT instance - an EC2 that acts as a router - but ran into configuration issues getting it to actually forward traffic. Ended up not going down that path for this project.

This temporary NAT gateway approach is good enough for a college project MVP with almost no users that gets destroyed in a few hours anyway.

Has anyone dealt with this in production? Is there a cleaner pattern for private subnet internet access beyond NAT gateway or NAT instance?

#Terraform #AWS #VPC #CloudComputing #IaC #CloudCost

Steps to Deploy

Clone the repo

git clone https://github.com/ShobanChiddarth/alumni-connect-terraform
cd alumni-connect-terraform/infrastructure

Set AWS credentials

export AWS_ACCESS_KEY_ID="..."
export AWS_SECRET_ACCESS_KEY="..."

Set the database password
```
export TF_VAR_db_password="..."
```
Deploy
```
terraform init
terraform apply
```

Destroy the NAT gateway after apply

terraform destroy \
 -target=aws_nat_gateway.alumni-nat-gw \
 -target=aws_eip.nat-gateway-elastic-ip

To tear down everything:

terraform destroy

Proof of Deployment

These are screenshots I took when it was live. I then destroyed the whole infrastructure.

I archived the API landing URL (first image) in Wayback Machine. Here is the link: https://web.archive.org/web/20260322130840/http://alumni-alb-backend-83642402.ap-south-1.elb.amazonaws.com/

Conclusion

This is the full Terraform infrastructure for the alumni-connect backend.

IAM Development Lab in Keycloak

Shoban Chiddarth — Fri, 20 Mar 2026 17:17:13 +0000

Introduction

This is the ultimate IAM development and employee lifecycle management lab I am doing where I will be making use of the skills I learnt from the TATA virtual internship via Forage: Cybersecurity Analyst - IAM Developer to develop and implement an IAM solution for a fictional organization.

I chose Keycloak for this lab instead of SailPoint with Oracle Identity Manager because Keycloak is fully open source. This is a standalone lab independent of OpenLDAP.

The internship covered

IAM fundamentals
Digital identity
Authentication
Authorization
SSO
least privilege principle And then walked through designing and planning a full IAM implementation for a fictional enterprise called TechCorp (but the fictional org we will be representing is called Acme). The proposed solution used
SailPoint for automated user lifecycle management and
Oracle Identity Manager for RBAC with a four-phase implementation plan covering deployment, testing, training, and ongoing monitoring.

This lab takes those same requirements and implements them end-to-end:

A structured org with departments and roles
RBAC enforced at the role level
Full user lifecycle management from provisioning to offboarding
MFA
SSO via OIDC
Email-based verification flows
Brute force protection
Audit logging All running on-premises in VirtualBox with no external dependencies. ## Pre-Requisites

Build Log

Keycloak Server Initialization

I cloned a debian server VM, put it in the current VirtualBox host only network I have, assigned a static IP (192.168.57.8), Then I edited its hostname, and mapped DNS record keycloak.acme.internal -> 192.168.57.8 in Pi-Hole.

debian@keycloak:~$ sudo ifconfig enp0s3
enp0s3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.57.8  netmask 255.255.255.0  broadcast 192.168.57.255
        inet6 fe80::43b5:ca52:a96d:134a  prefixlen 64  scopeid 0x20<link>
        ether 08:00:27:8a:4a:29  txqueuelen 1000  (Ethernet)
        RX packets 28569  bytes 3772704 (3.5 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 28550  bytes 2712767 (2.5 MiB)
        TX errors 0  dropped 2 overruns 0  carrier 0  collisions 0

debian@keycloak:~$ nslookup keycloak.acme.internal
Server:     192.168.57.3
Address:    192.168.57.3#53

Name:   keycloak.acme.internal
Address: 192.168.57.8

debian@keycloak:~$

Then I installed java on it because Keycloak requires it.

sudo apt install default-jre -y

Java version 21 btw

debian@keycloak:~$ java --version
openjdk 21.0.10 2026-01-20
OpenJDK Runtime Environment (build 21.0.10+7-Debian-1deb13u1)
OpenJDK 64-Bit Server VM (build 21.0.10+7-Debian-1deb13u1, mixed mode, sharing)

Then I downloaded Keycloak from GitHub, extracted it and put it in /opt

debian@keycloak:~/Downloads$ ls
keycloak-26.5.6.tar.gz
debian@keycloak:~/Downloads$ tar -xzf keycloak-26.5.6.tar.gz 
debian@keycloak:~/Downloads$ ls
keycloak-26.5.6  keycloak-26.5.6.tar.gz
debian@keycloak:~/Downloads$ sudo mv keycloak-26.5.6 /opt/keycloak
debian@keycloak:~/Downloads$ cd /opt
debian@keycloak:/opt$ ls
keycloak
debian@keycloak:/opt$

And created a new user and set appropriate permissions.

sudo useradd -r -s /sbin/nologin keycloak
sudo chown -R keycloak:keycloak /opt/keycloak

Local CA certificates for Keycloak

I did the usual, created certs for keycloak.acme.internal and moved them to the Keycloak server and pointed Keycloak to it.

debian@keycloak:~/acme-certs$ ls
keycloak.acme.internal-key.pem  keycloak.acme.internal.pem
debian@keycloak:~/acme-certs$ sudo mkdir -p /opt/keycloak/conf/certs
debian@keycloak:~/acme-certs$ sudo cp keycloak.acme.internal.pem /opt/keycloak/conf/certs/keycloak.crt
debian@keycloak:~/acme-certs$ sudo cp keycloak.acme.internal-key.pem /opt/keycloak/conf/certs/keycloak.key
debian@keycloak:~/acme-certs$ sudo chown -R keycloak:keycloak /opt/keycloak/conf/certs
debian@keycloak:~/acme-certs$ sudo chmod 640 /opt/keycloak/conf/certs/keycloak.key
debian@keycloak:~/acme-certs$ sudo nano /opt/keycloak/conf/keycloak.conf 
debian@keycloak:~/acme-certs$ cat /opt/keycloak/conf/
cache-ispn.xml  certs/          keycloak.conf   README.md       truststores/    
debian@keycloak:~/acme-certs$ cat /opt/keycloak/conf/keycloak.conf | head -5
hostname=keycloak.acme.internal
https-certificate-file=/opt/keycloak/conf/certs/keycloak.crt
https-certificate-key-file=/opt/keycloak/conf/certs/keycloak.key
http-enabled=false

debian@keycloak:~/acme-certs$

Keycloak initial build

sudo -u keycloak KEYCLOAK_ADMIN=admin KEYCLOAK_ADMIN_PASSWORD=admin123 /opt/keycloak/bin/kc.sh build

Output:

debian@keycloak:~/acme-certs$ sudo -u keycloak KEYCLOAK_ADMIN=admin KEYCLOAK_ADMIN_PASSWORD=password /opt/keycloak/bin/kc.sh build
WARNING: Usage of the default value for the db option in the production profile is deprecated. Please explicitly set the db instead.
INFO: The following run time options were found, but will be ignored during build time: kc.https-certificate-key-file, kc.http-enabled, kc.hostname, kc.https-certificate-file

Updating the configuration and installing your custom providers, if any. Please wait.
2026-03-19 20:00:27,827 INFO  [io.quarkus.deployment.QuarkusAugmentor] (main) Quarkus augmentation completed in 10529ms
Server configuration updated and persisted. Run the following command to review the configuration:

    kc.sh show-config

debian@keycloak:~/acme-certs$ /opt/keycloak/bin/kc.sh show-config
Current Mode: production
Current Configuration:
    kc.log-level-org.infinispan.transaction.lookup.JBossStandaloneJTAManagerLookup =  null (Derived)
    kc.log-level-io.quarkus.config =  null (Derived)
    kc.hostname =  keycloak.acme.internal (keycloak.conf)
    kc.log-console-output =  default (classpath application.properties)
    kc.log-level-io.quarkus.hibernate.orm.deployment.HibernateOrmProcessor =  null (Derived)
    kc.log-level-liquibase.database.core.PostgresDatabase =  null (Derived)
    kc.optimized =  true (Persisted)
    kc.version =  26.5.6 (SysPropConfigSource)
    kc.log-level-io.smallrye.openapi.runtime.scanner.dataobject =  null (Derived)
    kc.https-certificate-file =  /opt/keycloak/conf/certs/keycloak.crt (keycloak.conf)
    kc.log-level-org.jboss.resteasy.resteasy_jaxrs.i18n =  null (Derived)
    kc.log-level-io.quarkus.arc.processor.BeanArchives =  null (Derived)
    kc.log-level-io.quarkus.deployment.steps.ReflectiveHierarchyStep =  null (Derived)
    kc.http-enabled =  false (keycloak.conf)
    kc.log-level-org.hibernate.SQL_SLOW =  null (Derived)
    kc.https-certificate-key-file =  /opt/keycloak/conf/certs/keycloak.key (keycloak.conf)
    kc.log-level-io.quarkus.arc.processor.IndexClassLookupUtils =  null (Derived)
    kc.log-file =  /opt/keycloak/bin/../data/log/keycloak.log (classpath application.properties)
    kc.log-level-org.hibernate.engine.jdbc.spi.SqlExceptionHelper =  null (Derived)
debian@keycloak:~/acme-certs$

Keycloak daemon build (systemd)

I created a file /etc/systemd/system/keycloak.service with contents

[Unit]
Description=Keycloak Identity and Access Management
After=network.target

[Service]
User=keycloak
Group=keycloak
Environment=KEYCLOAK_ADMIN=admin
Environment=KEYCLOAK_ADMIN_PASSWORD=admin123
ExecStart=/opt/keycloak/bin/kc.sh start
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

And enabled the service

debian@keycloak:~/acme-certs$ sudo systemctl daemon-reload
debian@keycloak:~/acme-certs$ sudo systemctl enable --now keycloak
Created symlink '/etc/systemd/system/multi-user.target.wants/keycloak.service' → '/etc/systemd/system/keycloak.service'.
debian@keycloak:~/acme-certs$ sudo systemctl status keycloak
● keycloak.service - Keycloak Identity and Access Management
     Loaded: loaded (/etc/systemd/system/keycloak.service; enabled; preset: enabled)
     Active: active (running) since Thu 2026-03-19 20:05:40 IST; 6s ago
 Invocation: cde0a8f017a24bac8dd23934aa7a5bf2
   Main PID: 3250 (kc.sh)
      Tasks: 29 (limit: 2301)
     Memory: 269.9M (peak: 270.2M)
        CPU: 6.151s
     CGroup: /system.slice/keycloak.service
             ├─3250 /bin/sh /opt/keycloak/bin/kc.sh start
             └─3322 java -Djava.util.concurrent.ForkJoinPool.common.threadFactory=io.quarkus.bootstrap.forkjoin.QuarkusForkJoinW>

Mar 19 20:05:40 keycloak.acme.internal systemd[1]: Started keycloak.service - Keycloak Identity and Access Management.
Mar 19 20:05:46 keycloak.acme.internal kc.sh[3322]: 2026-03-19 20:05:46,328 INFO  [org.hibernate.orm.jdbc.batch] (JPA Startup Th>
debian@keycloak:~/acme-certs$

Keycloak admin dashboard

I visited https://keycloak.acme.internal:8443 from where the rootCA.pem was trusted in the OS as well as browser certificate store.

Then signed in.

And then created a permanent admin account as it says. I created a new user with username administrator, set a password, and then assigned admin role to it. Then logged in with that user and deleted the temporary admin user.

Then I created a realm for our fictional org - acme - with display name "Acme Corp", user self-registration disabled (admin-provisioned org), and email verification enabled.

Mailpit initial setup

Since this is a local lab with no real mail infrastructure, I used Mailpit - a lightweight fake SMTP server that catches all outbound emails and displays them in a web UI instead of actually delivering them. This lets me test Keycloak's email flows (verification, password reset, OTP) without setting up a real mail server or domain. I ran it on the same VM as Keycloak since it's a single binary with minimal resource usage.

I installed mailpit from GitHub, on the same VM as Keycloak.

wget https://github.com/axllent/mailpit/releases/download/v1.29.3/mailpit-linux-amd64.tar.gz
mkdir mailpit
tar -xzf mailpit-linux-amd64.tar.gz -C mailpit
cd mailpit
sudo mv mailpit /usr/local/bin/
sudo chmod +x /usr/local/bin/mailpit

And then verified it

$ mailpit version
mailpit v1.29.3 compiled with go1.26.1 on linux/amd64
Error checking for latest release: failed to fetch releases: received status code 403

And I created a new user for it

sudo useradd -r -s /sbin/nologin mailpit

Mailpit daemon build (systemd)

I put the following contents on /etc/systemd/system/mailpit.service (copied the previously generated keys to /etc/mailpit/certs and changed ownership of that folder to mailpit)

# /etc/systemd/system/mailpit.service
[Unit]
Description=Mailpit SMTP and Web UI
After=network.target

[Service]
User=mailpit
Group=mailpit
ExecStart=/usr/local/bin/mailpit --smtp 0.0.0.0:1025 --listen 0.0.0.0:8025 --ui-tls-cert /etc/mailpit/certs/keycloak.acme.internal.pem --ui-tls-key /etc/mailpit/certs/keycloak.acme.internal-key.pem
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

And ran

sudo systemctl daemon-reload
sudo systemctl enable --now mailpit
sudo systemctl status mailpit

It works

debian@keycloak:~/Downloads/mailpit$ sudo systemctl daemon-reload
sudo systemctl enable --now mailpit
sudo systemctl status mailpit
Created symlink '/etc/systemd/system/multi-user.target.wants/mailpit.service' → '/etc/systemd/system/mailpit.service'.
● mailpit.service - Mailpit SMTP and Web UI
     Loaded: loaded (/etc/systemd/system/mailpit.service; enabled; preset: enab>
     Active: active (running) since Fri 2026-03-20 15:37:36 IST; 67ms ago
 Invocation: 1046374b8fb24c4f92c8a6fe9683cb5f
   Main PID: 2010 (mailpit)
      Tasks: 3 (limit: 2301)
     Memory: 8.7M (peak: 8.7M)
        CPU: 13ms
     CGroup: /system.slice/mailpit.service
             └─2010 /usr/local/bin/mailpit --smtp 0.0.0.0:1025 --listen 0.0.0.0>

Mar 20 15:37:36 keycloak.acme.internal systemd[1]: Started mailpit.service - Ma>
Mar 20 15:37:36 keycloak.acme.internal mailpit[2010]: time="2026/03/20 15:37:36>
Mar 20 15:37:36 keycloak.acme.internal mailpit[2010]: time="2026/03/20 15:37:36>
Mar 20 15:37:36 keycloak.acme.internal mailpit[2010]: time="2026/03/20 15:37:36>
Mar 20 15:37:36 keycloak.acme.internal mailpit[2010]: time="2026/03/20 15:37:36>
debian@keycloak:~/Downloads/mailpit$

Keycloak to use Mailpit for email

After I created the ACME Corp realm on Keycloak, I went to Realm Settings, email, entered these values to make use of Mailpit as email service.

Then I visited Mailpit dashboard at https://keycloak.acme.internal:8025/

It works.

Password Policy in Keycloak

I went to Authentication -> Password Policy -> Password Policies and set the password requirements to have

Minimum 10 characters
Minimum 1 Uppercase
Minimum 1 Lowercase
Minimum 1 Digit
Minimum 1 Special Character
Password history: 3 (prevents reuse of last 3 passwords)

I also configured brute force detection under Realm Settings -> Security Defenses -> Brute force detection:

Brute Force Mode: Lockout permanently after temporary lockout
Max login failures: 5
Maximum temporary lockouts: 1
Strategy to increase wait time: Multiple
Wait increment: 1 minute
Max wait: 15 minutes
Failure reset time: 12 hours

After 5 failed login attempts the account locks out temporarily. If login failures continue through the temporary lockout, the account gets permanently locked and requires an admin to manually re-enable it. This will be demonstrated later in the user lifecycle section using Burp Suite to capture the login request and a Python script to simulate a brute force attack with a wordlist.

Organization Structure

I created the above organization structure in Keycloak - four groups for departments, three realm roles (employee, manager, it-admin), and seven users provisioned and assigned accordingly.

All users:

Group Engineering:

Group Finance:

Group HR:

.png)

Group IT:

Role employee:

Role manager:

Role IT Admin:

Enforcing MFA via TOTP (Google Authenticator)

I set up password based logins for users (Something You Know). Now I will set up Google Authenticator based 2FA (Something You Have). For this lab, I will be using gauth.apps.gbraad.nl, a browser based Google Authenticator app implementation, on the host machine, as my Google Authenticator client.

I duplicated the default browser authentication flow in Authentication -> Flows, named it acme browser, and set the Browser - Conditional OTP step from Conditional to Required. Then under Authentication -> Bindings, I set the Browser flow to acme browser. This forces TOTP on every login for all users in the acme realm.

I also enabled the following required actions under Authentication -> Required actions:

Update Password
Verify Email
Configure OTP

These are applied to all users, so on first login every user is forced to change their temporary password, verify their email via Mailpit, and set up TOTP before they can access anything.

jsmith is forced to setup Google Authenticator login in next successful login:

jsmith added key to Google Authenticator

jsmith enters the OTP value and logs in successfully. Every other account did the same.

OIDC Client and SSO Demo

To demonstrate SSO, I registered a client in the acme realm pointing to the official Keycloak demo app hosted at https://www.keycloak.org/app/. Since it's a static page that runs entirely in the browser, it talks directly to my local Keycloak instance - no server-side component needed.

Client settings:

Client type: OpenID Connect
Client authentication: Off (public client)
Valid redirect URIs: https://www.keycloak.org/app/*
Valid post logout redirect URIs: https://www.keycloak.org/app/*
Web origins: https://www.keycloak.org

On the demo app, I pointed it at my Keycloak instance by entering the server URL, realm, and client ID.

Clicking Sign In redirected to the Keycloak login page, went through the full authentication flow - password then TOTP - and landed back on the demo app showing jsmith's authenticated session with the decoded token.

Employee lifecycle management

To demonstrate the full employee lifecycle, I walked through four real-world IAM events using mclark from the HR department.

1. mclark gets promoted to HR manager

mclark was promoted from HR employee to HR manager. In Keycloak, this meant removing the employee role and assigning manager under the user's Role Mappings tab.

Before:

After:

2. mclark takes a vacation (account disabled)

mclark went on an extended leave of absence. Rather than deleting the account, it was disabled - access is immediately revoked but the account and its data remain intact for when the employee returns.

3. mclark returns (account enabled)

mclark returned from leave. The account was re-enabled, restoring access with all roles and group memberships unchanged.

4. mclark quits (account deleted)

mclark resigned. The account was permanently deleted from the realm.

Confirmation:

mclark is no more:

Brute Force Protection

Now I am going to do a brute force attack on jsmith's account. I am going to manually type in some random password values and hit enter multiple times to see what happens.

As you can see from the admin dashboard, jsmith is now temporarily locked.

Event log

Keycloak captures two categories of events per realm. Login events record every authentication-related action - successful logins, failed attempts, logouts, and token operations. Admin events record every administrative action performed on the realm - user creation, role assignments, deletions, client configuration changes, and so on. Both are visible under Events in the admin console.

Login Events

Here is a snippet of lwilson signin related events

Admin Events

Here is a snippet of admin events related to jsmith getting promoted

Conclusion

The internship asked for a designed IAM solution and an implementation plan. This lab is that plan executed.

Every requirement from the Tata Forage simulation is covered here in a working deployment:

Keycloak handles identity and access management for Acme Corp the same way SailPoint and Oracle Identity Manager would handle it for TechCorp.
RBAC is enforced through realm roles mapped to job functions.
User provisioning and de-provisioning follow the same lifecycle model - onboarding with required actions, role changes on promotion, account suspension on leave, and full deletion on resignation.
MFA via TOTP enforces the "something you know + something you have" authentication standard.
SSO via OIDC demonstrates seamless access across applications from a single authenticated session.
Mailpit handles all email flows locally.
Brute force protection is configured and verified.
Admin and login events are captured in the audit log.

The entire stack - Keycloak, Mailpit, TLS via a local CA, DNS via Pi-hole, and network routing via pfSense - runs self-contained in VirtualBox, making it fully reproducible as a home lab without any cloud dependency or paid tooling.

Integrating a local mail server into my LDAP lab

Shoban Chiddarth — Thu, 19 Mar 2026 07:38:19 +0000

GitHub Repo: @ShobanChiddarth/postfix-dovecot-mailserver-in-openldap-lab

Introduction

This is the second stage of my OpenLDAP home lab. I set up a mail server to work with existing LDAP configuration.

Pre-Requisites

Setup Process

Mail Server Install

In the existing setup, I cloned another debian server VM, gave it static IP 192.168.57.7, set its hostname to mail-server.acme.internal and then added the DNS record in Pi-hole. Then I went ahead and installed the required packages for postfix and dovecot to work with LDAP.

sudo apt install -y postfix postfix-ldap dovecot-core dovecot-imapd dovecot-ldap dovecot-lmtpd

Then I chose "Internet Site" in the postfix install prompt asking about which type of mail server to install and set the domain to acme.internal.

Postfix Config

I edited /etc/postfix/main.cf to have this configuration:

myhostname = mail-server.acme.internal
mydomain = acme.internal
mydestination = $myhostname, $mydomain, localhost
mynetworks = 192.168.57.0/24 127.0.0.0/8
inet_interfaces = all
mailbox_transport = lmtp:unix:private/dovecot-lmtp
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
local_recipient_maps = ldap:/etc/postfix/ldap-recipients.cf

mailbox_transport hands mail delivery off to Dovecot via LMTP. The smtpd_sasl_* settings let Postfix use Dovecot for SMTP authentication. local_recipient_maps tells Postfix to look up valid recipients in LDAP instead of the local user table - without this, Postfix rejects mail to LDAP users with "User unknown in local recipient table".

I created /etc/postfix/ldap-recipients.cf for the recipient lookup:

server_host = ldaps://ldap-server.acme.internal
bind = yes
bind_dn = cn=sssd,ou=service-accounts,dc=acme,dc=internal
bind_pw = SSSDPass123
search_base = ou=users,dc=acme,dc=internal
query_filter = (&(objectClass=posixAccount)(mail=%s))
result_attribute = mail

Then reloaded Postfix:

sudo systemctl reload postfix

Local CA Config on Mail Server

I copied rootCA.pem that I created earlier to this server and trusted it.

debian@mail-server:~/acme-certs$ ls
rootCA.pem
debian@mail-server:~/acme-certs$ sudo cp rootCA.pem /usr/local/share/ca-certificates/acme-rootCA.crt
[sudo] password for debian: 
debian@mail-server:~/acme-certs$ sudo update-ca-certificates
Updating certificates in /etc/ssl/certs...
rehash: warning: skipping ca-certificates.crt, it does not contain exactly one certificate or CRL
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
debian@mail-server:~/acme-certs$

Dovecot TLS Config

I generated a TLS cert for mail-server.acme.internal using mkcert and copied it to the server:

sudo cp mail-server.acme.internal.pem /etc/dovecot/private/mail-server.crt
sudo cp mail-server.acme.internal-key.pem /etc/dovecot/private/mail-server.key
sudo chown root:dovecot /etc/dovecot/private/mail-server.key
sudo chmod 640 /etc/dovecot/private/mail-server.key

Then updated /etc/dovecot/conf.d/10-ssl.conf:

ssl_server_cert_file = /etc/dovecot/private/mail-server.crt
ssl_server_key_file = /etc/dovecot/private/mail-server.key

Dovecot LDAP Config

I changed dovecot auth settings to use LDAP auth instead of system auth by editing /etc/dovecot/conf.d/10-auth.conf - commented out auth-system.conf.ext and uncommented auth-ldap.conf.ext.

debian@mail-server:~/acme-certs$ cat /etc/dovecot/conf.d/10-auth.conf | grep "include auth"
#!include auth-deny.conf.ext
#!include auth-master.conf.ext
#!include auth-oauth2.conf.ext
#!include auth-system.conf.ext
#!include auth-sql.conf.ext
!include auth-ldap.conf.ext
#!include auth-passwdfile.conf.ext
#!include auth-static.conf.ext

Dovecot 2.4 changed the config syntax from older versions, so the standard examples online did not work. After checking the example config the package ships with, I set /etc/dovecot/conf.d/auth-ldap.conf.ext to:

ldap_uris = ldaps://ldap-server.acme.internal
ldap_auth_dn = cn=sssd,ou=service-accounts,dc=acme,dc=internal
ldap_auth_dn_password = SSSDPass123
ldap_base = ou=users,dc=acme,dc=internal

passdb ldap {
  ldap_filter = (&(objectClass=posixAccount)(uid=%{user}))
  ldap_bind = yes
}

userdb ldap {
  ldap_filter = (&(objectClass=posixAccount)(uid=%{user}))
  fields {
    uid = vmail
    gid = vmail
    home = /var/mail/vhosts/%{user | username}
  }
}

This reuses the same read-only service account from the LDAP lab. ldap_bind = yes means Dovecot verifies passwords by actually binding to LDAP as the user rather than fetching and comparing the hash. The userdb block maps all mail storage to a dedicated vmail system user instead of running as the LDAP user's UID.

Note: ldap_auth_dn_password is stored in plaintext, but /etc/dovecot/conf.d/auth-ldap.conf.ext is owned by root and not readable by other users.

Dovecot Mail Storage and Postfix Integration

Since LDAP users don't have home directories on the mail server, I created a dedicated vmail system user to own all mailboxes and set up a central mail storage directory:

sudo adduser --system --no-create-home --group vmail
sudo mkdir -p /var/mail/vhosts
sudo chown -R vmail:vmail /var/mail/vhosts
sudo chmod 770 /var/mail/vhosts

I updated /etc/dovecot/conf.d/10-mail.conf to use this path:

mail_driver = maildir
mail_home = /var/mail/vhosts/%{user | username}
mail_path = %{home}/Maildir
first_valid_uid = 100

Then I configured the LMTP and auth unix sockets in /etc/dovecot/conf.d/10-master.conf so Postfix can hand off incoming mail to Dovecot and use Dovecot for SMTP authentication.

In the service lmtp block:

service lmtp {
  unix_listener /var/spool/postfix/private/dovecot-lmtp {
    mode = 0600
    user = postfix
    group = postfix
  }
}

In the service auth block:

service auth {
  unix_listener /var/spool/postfix/private/auth {
    mode = 0660
    user = postfix
    group = postfix
  }
}

Then restarted Dovecot:

sudo systemctl restart dovecot

Verification

Sending mail

I sent a test mail from jsmith to adoe over SMTP from a desktop VM on the same network:

debian@debian:~/acme-certs$ curl -v --url "smtp://mail-server.acme.internal:25" \
  --mail-from "jsmith@acme.internal" \
  --mail-rcpt "adoe@acme.internal" \
  --upload-file - <<EOF
From: jsmith@acme.internal
To: adoe@acme.internal
Subject: Test from jsmith

Hello Alice, this is John.
EOF

Postfix accepted it and delivered it to Dovecot via LMTP:

250 2.0.0 Ok: queued as 98B624018B

Verified the mail landed in adoe's mailbox on the server:

debian@mail-server:~$ sudo ls /var/mail/vhosts/adoe/Maildir/new/
1773903163.M693787P7845.mail-server.acme.internal,S=560,W=576

Retrieving mail over IMAPS

I verified that adoe can authenticate and retrieve mail over IMAPS using their LDAP credentials:

debian@debian:~/acme-certs$ curl -v --url "imaps://mail-server.acme.internal/INBOX" \
  --user "adoe:Password456"

* SSL certificate verify ok.
* Connected to mail-server.acme.internal (192.168.57.7) port 993
< A002 OK Logged in
< * LIST (\HasNoChildren) "." INBOX
< A003 OK List completed (0.001 + 0.000 secs).

TLS handshake succeeded using the mkcert CA, LDAP authentication worked, and the INBOX is accessible.

Thunderbird Verification

Thunderbird has its own certificate store separate from the system trust store, so I had to manually import rootCA.pem into Thunderbird settings before it would trust the IMAPS connection.

adoe sends an email to jsmith

jsmith opens it

jsmith sends a reply email to adoe

adoe views the reply email

Conclusion

Postfix and Dovecot are now running as a mail server for acme.internal. Users defined in the OpenLDAP directory can send and receive mail using their LDAP credentials. Postfix looks up valid recipients in LDAP so it accepts mail for LDAP users. Dovecot authenticates over LDAPS using the same read-only service account from the LDAP lab and stores mail in a central directory owned by a dedicated vmail user. IMAP access is over TLS only.

This mail server will be used in the next part of this series as the SMTP backend for Keycloak notifications.

OpenLDAP home lab - Cyber Security technical write up

Shoban Chiddarth — Tue, 17 Mar 2026 07:55:15 +0000

GitHub Repo: @ShobanChiddarth/openldap-iam-lab

Introduction

This home lab is a part of my setup for an IAM lab using KeyCloak. In this lab I set up OpenLDAP in a Virtualbox lab.

Pre-Requisites

Setup Process

Let's say the fictional organization I am working in is Acme Inc. The domain name would be acme.internal. I have the VM intercommunication setup that I linked earlier ready. I also setup custom DNS records in the Pi-hole (ldap-server.acme.internal points to 192.168.57.5 and ldap-client.acme.internal points to 192.168.57.6).

Setting up LDAP server

I installed slapd and ldap-utils

sudo apt update
sudo apt install slapd ldap-utils

And set the admin password mid installation, then configured it with

sudo dpkg-reconfigure slapd

It asked me for organization name along with domain, I filled in with the appropriate details. And verified it with

debian@ldap-server:~$ sudo slapcat
dn: dc=acme,dc=internal
objectClass: top
objectClass: dcObject
objectClass: organization
o: Acme
dc: acme
structuralObjectClass: organization
entryUUID: 2938c77a-b601-1040-8564-d9abd6bd9b70
creatorsName: cn=admin,dc=acme,dc=internal
createTimestamp: 20260317035728Z
entryCSN: 20260317035728.729122Z#000000#000#000000
modifiersName: cn=admin,dc=acme,dc=internal
modifyTimestamp: 20260317035728Z

Creating Directory structure

I created structure.ldif to add two organizational units - one for users and one for groups, and loaded it.

debian@ldap-server:~$ nano structure.ldif
debian@ldap-server:~$ cat structure.ldif 
dn: ou=users,dc=acme,dc=internal
objectClass: organizationalUnit
ou: users

dn: ou=groups,dc=acme,dc=internal
objectClass: organizationalUnit
ou: groups
debian@ldap-server:~$ ldapadd -x -D "cn=admin,dc=acme,dc=internal" -W -f structure.ldif
Enter LDAP Password: 
adding new entry "ou=users,dc=acme,dc=internal"

adding new entry "ou=groups,dc=acme,dc=internal"

Adding users

I will be creating 2 users "John Smith" and "Alice Doe" with passwords Password123 and Password456 respectively. I generated the password hashes using

debian@ldap-server:~$ sudo /usr/sbin/slappasswd -s Password123
{SSHA}2sIS9koZfMFfwEjWoglS4Iu8XpCvamLk
debian@ldap-server:~$ sudo /usr/sbin/slappasswd -s Password456
{SSHA}QlqSwZdrWeINW5PS54vTx4Bpqt+6PLdi
debian@ldap-server:~$

Then created 2 users in users.ldif and loaded them.

debian@ldap-server:~$ nano users.ldif
debian@ldap-server:~$ cat users.ldif 
dn: uid=jsmith,ou=users,dc=acme,dc=internal
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: jsmith
sn: Smith
givenName: John
cn: John Smith
displayName: John Smith
uidNumber: 10001
gidNumber: 10001
userPassword: {SSHA}2sIS9koZfMFfwEjWoglS4Iu8XpCvamLk
loginShell: /bin/bash
homeDirectory: /home/jsmith
mail: jsmith@acme.internal

dn: uid=adoe,ou=users,dc=acme,dc=internal
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: adoe
sn: Doe
givenName: Alice
cn: Alice Doe
displayName: Alice Doe
uidNumber: 10002
gidNumber: 10002
userPassword: {SSHA}QlqSwZdrWeINW5PS54vTx4Bpqt+6PLdi
loginShell: /bin/bash
homeDirectory: /home/adoe
mail: adoe@acme.internal
debian@ldap-server:~$ ldapadd -x -D "cn=admin,dc=acme,dc=internal" -W -f users.ldif
Enter LDAP Password: 
adding new entry "uid=jsmith,ou=users,dc=acme,dc=internal"

adding new entry "uid=adoe,ou=users,dc=acme,dc=internal"

Adding groups

I created groups engineering and HR, added jsmith to engineering and Alice to HR, and loaded them.

debian@ldap-server:~$ nano groups.ldif
debian@ldap-server:~$ cat groups.ldif 
dn: cn=engineers,ou=groups,dc=acme,dc=internal
objectClass: posixGroup
cn: engineers
gidNumber: 10001
memberUid: jsmith

dn: cn=hr,ou=groups,dc=acme,dc=internal
objectClass: posixGroup
cn: hr
gidNumber: 10002
memberUid: adoe
debian@ldap-server:~$ ldapadd -x -D "cn=admin,dc=acme,dc=internal" -W -f groups.ldif
Enter LDAP Password: 
adding new entry "cn=engineers,ou=groups,dc=acme,dc=internal"

adding new entry "cn=hr,ou=groups,dc=acme,dc=internal"

debian@ldap-server:~$

Setting up LDAPS (using mkcert)

I created TLS certificates for ldap-server.acme.internal.

debian@debian:~/acme-certs$ mkcert -install
Created a new local CA 💥
The local CA is now installed in the system trust store! ⚡️
ERROR: no Firefox and/or Chrome/Chromium security databases found

debian@debian:~/acme-certs$ mkcert -CAROOT
/home/debian/.local/share/mkcert
debian@debian:~/acme-certs$ cp $(mkcert -CAROOT)/rootCA.pem .
debian@debian:~/acme-certs$ ls
rootCA-key.pem  rootCA.pem
debian@debian:~/acme-certs$ mkcert ldap-server.acme.internal
Note: the local CA is not installed in the Firefox and/or Chrome/Chromium trust store.
Run "mkcert -install" for certificates to be trusted automatically ⚠️

Created a new certificate valid for the following names 📜
 - "ldap-server.acme.internal"

The certificate is at "./ldap-server.acme.internal.pem" and the key at "./ldap-server.acme.internal-key.pem" ✅

It will expire on 17 June 2028 🗓

debian@debian:~/acme-certs$ ls -l
total 16
-rw------- 1 debian debian 1704 Mar 17 09:55 ldap-server.acme.internal-key.pem
-rw-r--r-- 1 debian debian 1472 Mar 17 09:55 ldap-server.acme.internal.pem
-rw-r--r-- 1 debian debian 1619 Mar 17 09:54 rootCA.pem
debian@debian:~/acme-certs$

Copied those 3 files onto the server and set the required permissions.

debian@ldap-server:~/acme-certs$ ls
ldap-server.acme.internal-key.pem  ldap-server.acme.internal.pem  rootCA.pem
debian@ldap-server:~/acme-certs$ sudo mkdir -p /etc/ldap/tls
debian@ldap-server:~/acme-certs$ sudo cp ldap-server.acme.internal.pem /etc/ldap/tls/ldap-server.crt
debian@ldap-server:~/acme-certs$ sudo cp ldap-server.acme.internal-key.pem /etc/ldap/tls/ldap-server.key
debian@ldap-server:~/acme-certs$ sudo cp rootCA.pem /etc/ldap/tls/rootCA.pem
debian@ldap-server:~/acme-certs$ sudo chown -R openldap:openldap /etc/ldap/tls
debian@ldap-server:~/acme-certs$ sudo chmod 640 /etc/ldap/tls/ldap-server.key
debian@ldap-server:~/acme-certs$ sudo chmod 644 /etc/ldap/tls/ldap-server.crt /etc/ldap/tls/rootCA.pem
debian@ldap-server:~/acme-certs$ ls -l /etc/ldap/tls/
total 12
-rw-r--r-- 1 openldap openldap 1472 Mar 17 10:51 ldap-server.crt
-rw-r----- 1 openldap openldap 1704 Mar 17 10:51 ldap-server.key
-rw-r--r-- 1 openldap openldap 1619 Mar 17 10:51 rootCA.pem
debian@ldap-server:~/acme-certs$ ls -ld /etc/ldap/tls/
drwxr-xr-x 2 openldap openldap 4096 Mar 17 10:51 /etc/ldap/tls/
debian@ldap-server:~/acme-certs$

Then I created tls conf file (tls.ldif) and applied it.

debian@ldap-server:~$ nano tls.ldif
debian@ldap-server:~$ cat tls.ldif 
dn: cn=config
changetype: modify
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ldap/tls/rootCA.pem
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ldap/tls/ldap-server.crt
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ldap/tls/ldap-server.key
debian@ldap-server:~$ sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f tls.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "cn=config"

debian@ldap-server:~$

Then I set SLAPD_SERVICES in /etc/default/slapd to use LDAPS

SLAPD_SERVICES="ldapi:/// ldaps:///"

And specified LDAP client tools on the server to use the certificate

debian@ldap-server:~$ echo "TLS_CACERT /etc/ldap/tls/rootCA.pem" | sudo tee -a /etc/ldap/ldap.conf
TLS_CACERT /etc/ldap/tls/rootCA.pem
debian@ldap-server:~$

Then I restarted slapd service and checked if LDAPS is working

debian@ldap-server:~$ sudo systemctl restart slapd
debian@ldap-server:~$ ldapsearch -x -H ldaps://ldap-server.acme.internal \
  -D "cn=admin,dc=acme,dc=internal" -W \
  -b "dc=acme,dc=internal" "(objectClass=*)"
Enter LDAP Password: 
# extended LDIF
#
# LDAPv3
# base <dc=acme,dc=internal> with scope subtree
# filter: (objectClass=*)
# requesting: ALL
#

# acme.internal
dn: dc=acme,dc=internal
objectClass: top
objectClass: dcObject
objectClass: organization
o: Acme
dc: acme

# users, acme.internal
dn: ou=users,dc=acme,dc=internal
objectClass: organizationalUnit
ou: users

# groups, acme.internal
dn: ou=groups,dc=acme,dc=internal
objectClass: organizationalUnit
ou: groups

# jsmith, users, acme.internal
dn: uid=jsmith,ou=users,dc=acme,dc=internal
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: jsmith
sn: Smith
givenName: John
cn: John Smith
displayName: John Smith
uidNumber: 10001
gidNumber: 10001
userPassword:: e1NTSEF9MnNJUzlrb1pmTUZmd0VqV29nbFM0SXU4WHBDdmFtTGs=
loginShell: /bin/bash
homeDirectory: /home/jsmith
mail: jsmith@acme.internal

# adoe, users, acme.internal
dn: uid=adoe,ou=users,dc=acme,dc=internal
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: adoe
sn: Doe
givenName: Alice
cn: Alice Doe
displayName: Alice Doe
uidNumber: 10002
gidNumber: 10002
userPassword:: e1NTSEF9UWxxU3daZHJXZUlOVzVQUzU0dlR4NEJwcXQrNlBMZGk=
loginShell: /bin/bash
homeDirectory: /home/adoe
mail: adoe@acme.internal

# engineers, groups, acme.internal
dn: cn=engineers,ou=groups,dc=acme,dc=internal
objectClass: posixGroup
cn: engineers
gidNumber: 10001
memberUid: jsmith

# hr, groups, acme.internal
dn: cn=hr,ou=groups,dc=acme,dc=internal
objectClass: posixGroup
cn: hr
gidNumber: 10002
memberUid: adoe

# search result
search: 2
result: 0 Success

# numResponses: 8
# numEntries: 7
debian@ldap-server:~$

But there was one small problem with this. The userPassword's base64 encoded SSHA has is visible. I am going to fix that using ACLs.

I created acls.ldif and set the contents and loaded it and verified it.

debian@ldap-server:~$ nano acls.ldif
debian@ldap-server:~$ cat acls.ldif 
dn: olcDatabase={1}mdb,cn=config
changetype: modify
replace: olcAccess
olcAccess: {0}to attrs=userPassword
  by self write
  by anonymous auth
  by dn="cn=admin,dc=acme,dc=internal" write
  by * none
olcAccess: {1}to attrs=shadowLastChange
  by self write
  by * read
olcAccess: {2}to *
  by self write
  by dn="cn=admin,dc=acme,dc=internal" write
  by * read
debian@ldap-server:~$ sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f acls.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "olcDatabase={1}mdb,cn=config"

debian@ldap-server:~$ ldapsearch -x -H ldaps://ldap-server.acme.internal \
  -b "dc=acme,dc=internal" "(uid=jsmith)" userPassword
# extended LDIF
#
# LDAPv3
# base <dc=acme,dc=internal> with scope subtree
# filter: (uid=jsmith)
# requesting: userPassword 
#

# jsmith, users, acme.internal
dn: uid=jsmith,ou=users,dc=acme,dc=internal

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1
debian@ldap-server:~$

Setting up LDAP client

I copied rootCA.pem to the LDAP client and trusted it.

debian@ldap-client:~/acme-certs$ ls
rootCA.pem
debian@ldap-client:~/acme-certs$ sudo cp rootCA.pem /usr/local/share/ca-certificates/acme-rootCA.crt
[sudo] password for debian: 
debian@ldap-client:~/acme-certs$ sudo update-ca-certificates
Updating certificates in /etc/ssl/certs...
rehash: warning: skipping ca-certificates.crt, it does not contain exactly one certificate or CRL
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
debian@ldap-client:~/acme-certs$

Then I installed System Security Services

sudo apt install -y sssd libpam-sss libnss-sss

I now created the configuration for it, set the permissions and enabled the service.

debian@ldap-client:~$ sudo nano /etc/sssd/sssd.conf
debian@ldap-client:~$ sudo cat /etc/sssd/sssd.conf
[sssd]
services = nss, pam
config_file_version = 2
domains = acme.internal

[domain/acme.internal]
id_provider = ldap
auth_provider = ldap
ldap_uri = ldaps://ldap-server.acme.internal
ldap_search_base = dc=acme,dc=internal
ldap_tls_cacert = /etc/ssl/certs/ca-certificates.crt
ldap_schema = rfc2307
cache_credentials = true
enumerate = true
debian@ldap-client:~$ sudo chmod 600 /etc/sssd/sssd.conf
debian@ldap-client:~$ sudo systemctl enable --now sssd
Synchronizing state of sssd.service with SysV service script with /usr/lib/systemd/systemd-sysv-install.
Executing: /usr/lib/systemd/systemd-sysv-install enable sssd
debian@ldap-client:~$

The only thing left is automatic home dir creation.

sudo pam-auth-update --enable mkhomedir

This will make sure a home directory is automatically created when john ssh-es into the ldap client.

LDAP Client Verification

debian@ldap-client:~$ id jsmith
uid=10001(jsmith) gid=10001(engineers) groups=10001(engineers)
debian@ldap-client:~$ getent passwd jsmith
jsmith:*:10001:10001:John Smith:/home/jsmith:/bin/bash
debian@ldap-client:~$ getent group engineers
engineers:*:10001:jsmith
debian@ldap-client:~$

LDAP client can see the users and groups set in the LDAP server.

SSH verification

From another desktop, copied rootCA.pem and trusted it.

debian@debian:~/acme-certs$ ls
rootCA.pem
debian@debian:~/acme-certs$ sudo cp rootCA.pem /usr/local/share/ca-certificates/acme-rootCA.crt
[sudo] password for debian: 
debian@debian:~/acme-certs$ sudo update-ca-certificates
Updating certificates in /etc/ssl/certs...
rehash: warning: skipping ca-certificates.crt, it does not contain exactly one certificate or CRL
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
debian@debian:~/acme-certs$

Now I tried to ssh login

debian@debian:~/acme-certs$ ssh jsmith@ldap-client.acme.internal
The authenticity of host 'ldap-client.acme.internal (192.168.57.6)' can't be established.
ED25519 key fingerprint is SHA256:wo67g9IGEfMUrZBC1KzzKlHS1G41PidIUGXZ5kTGmV0.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'ldap-client.acme.internal' (ED25519) to the list of known hosts.
jsmith@ldap-client.acme.internal's password: 
Creating directory '/home/jsmith'.
Linux ldap-client.acme.internal 6.12.73+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.73-1 (2026-02-17) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
jsmith@ldap-client:~$ pwd
/home/jsmith
jsmith@ldap-client:~$

It worked. Also the home dir was automatically created.

Stopping anonymous bind and setup a service account for LDAP client

I need a password hash for the service account first. So I ran

debian@ldap-server:~$ sudo /usr/sbin/slappasswd -s SSSDPass123
[sudo] password for debian: 
{SSHA}ASFdTu5vaW4YSytPSFTpTc1StjoC+giz
debian@ldap-server:~$

Then I put it in service accounts conf file and then load it

debian@ldap-server:~$ nano service-accounts.ldif
debian@ldap-server:~$ cat service-accounts.ldif 
dn: ou=service-accounts,dc=acme,dc=internal
objectClass: organizationalUnit
ou: service-accounts

dn: cn=sssd,ou=service-accounts,dc=acme,dc=internal
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: sssd
description: Read-only service account for SSSD
userPassword: {SSHA}ASFdTu5vaW4YSytPSFTpTc1StjoC+giz
debian@ldap-server:~$ ldapadd -x -H ldaps://ldap-server.acme.internal \
  -D "cn=admin,dc=acme,dc=internal" -W -f service-accounts.ldif
Enter LDAP Password: 
adding new entry "ou=service-accounts,dc=acme,dc=internal"

adding new entry "cn=sssd,ou=service-accounts,dc=acme,dc=internal"

debian@ldap-server:~$

And then I create another ACL to make sure I only allow that specific account and disallow anonymous binds

debian@ldap-server:~$ nano acls2.ldif
debian@ldap-server:~$ cat acls2.ldif 
dn: olcDatabase={1}mdb,cn=config
changetype: modify
replace: olcAccess
olcAccess: {0}to attrs=userPassword
  by self write
  by anonymous auth
  by dn="cn=admin,dc=acme,dc=internal" write
  by * none
olcAccess: {1}to attrs=shadowLastChange
  by self write
  by * read
olcAccess: {2}to *
  by self write
  by dn="cn=admin,dc=acme,dc=internal" write
  by dn="cn=sssd,ou=service-accounts,dc=acme,dc=internal" read
  by * none
debian@ldap-server:~$ sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f acls2.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "olcDatabase={1}mdb,cn=config"

debian@ldap-server:~$

Now I set the LDAP client to use those accounts and restart the service

debian@ldap-client:~$ sudo cat /etc/sssd/sssd.conf
[sssd]
services = nss, pam
config_file_version = 2
domains = acme.internal

[domain/acme.internal]
id_provider = ldap
auth_provider = ldap
ldap_uri = ldaps://ldap-server.acme.internal
ldap_search_base = dc=acme,dc=internal
ldap_tls_cacert = /etc/ssl/certs/ca-certificates.crt
ldap_schema = rfc2307
cache_credentials = true
enumerate = true
ldap_default_bind_dn = cn=sssd,ou=service-accounts,dc=acme,dc=internal
ldap_default_authtok = SSSDPass123
debian@ldap-client:~$ sudo systemctl restart sssd

Note: ldap_default_authtok is stored in plaintext, but sssd.conf is locked to root only via the chmod 600 set earlier, so it is not readable by other users on the system.

Verifying again

LDAP client records fetching:

debian@ldap-client:~$ id jsmith
uid=10001(jsmith) gid=10001(engineers) groups=10001(engineers)
debian@ldap-client:~$ getent passwd adoe
adoe:*:10002:10002:Alice Doe:/home/adoe:/bin/bash
debian@ldap-client:~$

SSH verification:

debian@debian:~/acme-certs$ ssh jsmith@ldap-client.acme.internal
jsmith@ldap-client.acme.internal's password: 
Linux ldap-client.acme.internal 6.12.73+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.73-1 (2026-02-17) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Tue Mar 17 11:43:45 2026 from 192.168.57.104
jsmith@ldap-client:~$

It is working. Only the LDAP client can call the LDAP servers and anonymous binds are disabled.

Screenshots

VBoxManager

ALL VMs

Conclusion

OpenLDAP is now running as the centralized identity backend for acme.internal. The directory is secured with LDAPS using the lab's mkcert CA. ACLs enforce least-privilege access - password hashes are not exposed to anyone except the admin, and anonymous binds are disabled entirely. A dedicated read-only service account is the only thing allowed to query the directory, which is what SSSD on ldap-client uses. Users that exist only in LDAP can SSH into ldap-client with their home directories created automatically on first login.

This is the identity foundation for the next part of this series - connecting Keycloak to this LDAP directory as its user backend.

Setting up HTTPS on my home lab

Shoban Chiddarth — Mon, 09 Mar 2026 03:22:10 +0000

Introduction

This is the third part of my physical network engineering home lab series of blogs. In this blog I will be sharing how I set up SSL on my home lab and then accessed locally hosted services without a warning in the browser.

And no I am not buying a domain like a lot of YouTubers do, I am going to use mkcert to manage the SSL certificates and install the certificate on each client device and make HTTPS work with no warning from the browser. I chose mkcert because manually configuring openssl certificates and maintaining a certificate hierarchy is tedious for a home lab.

The goal of enabling HTTPS is to securely access the Pi-hole admin panel, and other locally hosted services in the home lab.

Side note: SSL is deprecated and replaced with TLS but the term SSL certificates is used in slang and I will be going with that in this blog

Requirements

A Linux machine
package libnss3-tools
```
sudo apt install libnss3-tools
```
package mkcert. For Linux Mint you can download via apt
```
sudo apt install mkcert
```
but if it is not available via apt you have to download it from GitHub

Steps

Creating `rootCA`

This is the highest in the hierarchy of certificates and we will be copying the root certificate to other devices to make them work with HTTPS.

On your client machine (not the server), run
```
mkcert -install
```
After it is installed, run
```
mkcert -CAROOT
```
This will print the directory where the root key and the root certificate is stored. Make a note of it.

gray@OMEN-Slim-Gaming-Laptop-16:~/home-lab-tls$ mkcert -install
Created a new local CA 💥
The local CA is now installed in the system trust store! ⚡️
The local CA is now installed in the Firefox and/or Chrome/Chromium trust store (requires browser restart)! 🦊

gray@OMEN-Slim-Gaming-Laptop-16:~/home-lab-tls$ mkcert -CAROOT
/home/gray/.local/share/mkcert
gray@OMEN-Slim-Gaming-Laptop-16:~/home-lab-tls$

Creating Certificates

In a separate directory, run the following command. 2 files will be stored on that current directory which you will need to copy to the server.
```
mkcert domain-name.internal
```
I have created only for pi.hole because that is the only service I want to secure right now.

gray@OMEN-Slim-Gaming-Laptop-16:~/home-lab-tls$ mkcert pi.hole

Created a new certificate valid for the following names 📜
 - "pi.hole"

The certificate is at "./pi.hole.pem" and the key at "./pi.hole-key.pem" ✅

It will expire on 8 June 2028 🗓

gray@OMEN-Slim-Gaming-Laptop-16:~/home-lab-tls$ ls
pi.hole-key.pem  pi.hole.pem
gray@OMEN-Slim-Gaming-Laptop-16:~/home-lab-tls$

Combine those 2 files along with the rootCA.pem in this specific order

cat pi.hole-key.pem pi.hole.pem  $(mkcert -CAROOT)/rootCA.pem > pi.hole-combined.pem

Copy the combined file to the server, into the directory /etc/pihole
On the server, make sure the file is owned by user and group pihole and only the owner can read/write to it.

sudo chown pihole:pihole pi.hole-combined.pem                 
sudo chmod 600 pi.hole-combined.pem

Pointing the Pi-hole server to use these certificates

Edit this section in /etc/pihole/pihole.toml as shown

  [webserver.tls]
    # Path to the TLS (SSL) certificate file.
    #
    # All directories along the path must be readable and accessible by the user running
    # FTL (typically 'pihole'). This option is only required when at least one of
    # webserver.port is TLS. The file must be in PEM format, and it must have both,
    # private key and certificate (the *.pem file created must contain a 'CERTIFICATE'
    # section as well as a 'RSA PRIVATE KEY' section).
    #
    # The *.pem file can be created using `cp server.crt server.pem && cat server.key >>
    # server.pem` if you have these files instead
    #
    # Allowed values are:
    #     A valid TLS certificate file (*.pem)
    cert = "/etc/pihole/pi.hole-combined.pem"

    # Number of days the automatically generated self-signed TLS/SSL certificate will be
    # valid for.
    #
    # Defaults to 47 days. A minimum of 7 days is enforced.
    # Some devices may enforce shorter validity ranges. Note that defining a lower
    # validity range may require you to accept the self-signed certificate more often in
    # your browser.
    # Pi-hole will regenerate certificates it created itself two days prior to expiration.
    # If you are using your own certificate, you need to regenerate it yourself. In this
    # case, it is advised to set the validity range to 0 days, so that Pi-hole does not
    # try to regenerate your certificate. If you set the validity range to 0 days and
    # still try to generate a certificate, Pi-hole will set a fixed validity range of
    # roughly 30 years for the certificate.
    validity = 0

Replace cert variable with where you stored the combined certificate, and then restart Pi-hole.

sudo service pihole-FTL restart

Side Note: If nginx is running, disable it. Pi-hole's FTL has a built-in web server that handles TLS directly - Nginx will conflict with it on port 80/443.

sudo systemctl disable nginx --now

Verifying HTTPS on current device

Open https://pi.hole in the browser of the device you ran mkcert -install command on.

Verifying it on other devices

Copy the file $(mkcert -CAROOT)/rootCA.pem to other devices, and import to the device's certificates (instructions vary for each device, Google it) store and then open https://pi.hole on the browser.

Conclusion

The Pi-hole admin panel is now accessible over HTTPS with a trusted certificate - no browser warnings, no exceptions. Any other device on the network can be added by copying the rootCA.pem and importing it into the system trust store.

From here, the physical lab has DNS, ad-blocking, and HTTPS in place.

The Superior Way to make VMs communicate with each other as well as host, with internet access

Shoban Chiddarth — Sat, 07 Mar 2026 14:05:19 +0000

Introduction

On December 1, 2025, I made a LinkedIn post about setting up inter-VM networking with 3 VMs (a DHCP server, a web server and a client). The full details and a technical document are available in the post if you want to check it out.

The way I set up 3 VMs for inter-VM networking with internet access is

VMs are set to use "Virtualbox Host Only Ethernet Adapter"
Internet is shared to the adapter using Windows proprietary ICS ("Internet Connection Sharing") from Control Panel. It worked in a Windows host (I was temporarily using Windows at that time) because internet sharing is fully handled by Windows, and the inter-VM networking worked with no issues.

Now I am using a Linux host and need to set up inter-VM networking for a project, the same thing is not possible as ICS is a Windows proprietary service. A similar solution will require turning the host into a router and manually managing firewall entries and route tables every time a network segment is created or removed - invasive and hard to cleanly reverse. The other option is attaching two adapters to each VM: one for inter-VM and host communication, another for internet access - which gets complicated across several VMs and can cause issues with desktop environments and network managers.

There is a superior way to achieve the following:

VMs can communicate with each other
Host can communicate with VMs and vice versa
VMs can access the internet
Host does not need to be converted to a router
2 or more adapters do not need to be attached to every single VM
Nothing is permanently changed on the host that requires manual intervention to revert, everything stays in Virtualbox and goes away when you delete them

The solution is to run pfSense in a VM that acts as the router between network adapters, keeping everything contained inside VirtualBox.

Overview

The setup is simple: install pfSense inside a VM and attach two adapters to it.

The first adapter connects pfSense to the internet. You can use Bridged, NAT, or NAT Network - all three work as long as the host has internet access. (Bridged gives pfSense a real IP on your physical LAN; NAT and NAT Network are simpler and work without touching your router).

For more information on VirtualBox virtual networking, see the manual.

The second adapter is a VirtualBox Host Only Ethernet Adapter attached to a specific Host Only Network. This becomes the LAN side.

For every other VM in your lab, attach a single VirtualBox Host Only Ethernet Adapter and select the same Host Only Network you assigned to pfSense's LAN adapter.

In pfSense, assign the first adapter as WAN and the Host Only Ethernet Adapter as LAN.

Disable the VirtualBox built-in DHCP server for that Host Only Network, and configure DHCP inside pfSense instead.

Always boot pfSense before your lab VMs - it handles DHCP and routing for the entire network.

Steps

Install pfSense on VirtualBox

Download the pfSense ISO file from Netgate Shop
Click "New" on Virtual Box and fill in the name of the OS, select the ISO file.
Select OS: "BSD"; Distro: "FreeBSD"; OS Version: "FreeBSD 64 bit";

Select 2GB RAM and 4GB Hard Disk

Click on "Start" and then install the OS. By default, Virtualbox assigns the "NAT" adapter as the only interface. That is fine for now. Select that as the WAN interface in the installation process. For installing the OS, accept defaults for everything else.
After installation is over, shut the VM down instead of rebooting.
Go to VM's settings -> Storage and remove the ISO file.

Click "Ok" and then boot the VM up.

If it boots up to this state then it means that it is successful. Now you can reset the admin account and password, then shut it down.

Configuring interfaces on pfSense

Go to Virtualbox Networks and select "Host Only Networks". Create a new Host Only Network if you do not want to use the default. Note the subnet/CIDR block.
Go to Machines -> pfSense VM settings -> Network and enable a second adapter, and set it to VirtualBox Host Only Ethernet Adapter and then select the Host Only Network you wish to use it. Make sure to select "Allow All" in promiscuous mode. This allows pfSense to forward traffic on behalf of other VMs.

Click on "OK" and boot it up again.

Select "1" to configure interfaces. Then select no for VLANs, assign em0 as WAN interface and then em1 as LAN interface. Then confirm it.

Select 2 to set interface IP addresses. We need a static IP on the LAN interface because pfSense will be our DHCP server. Make sure you are setting up an IP that does not clash with the host, and lies in the same subnet as the VirtualBox Host only network, then choose to enable DHCP server on LAN. (IPv6 is optional). > Note: To find the host's IP on that network, go to VirtualBox Manager -> Networks -> Host Only Networks and select your network.

After it is done, access the static IP you set via a web browser from the host. Enter the username admin and the password you set up earlier.

pfSense web configuration

Click next on the welcome messages and on the initial configuration, enter the appropriate values as shown in the image. Make sure to set up a valid upstream DNS resolver.

Leave the timeserver as is, and choose your timezone.

Click next and you will be asked to configure WAN and LAN interfaces. Change nothing as you already set this one up.
Set the admin account password again when it prompts you to and then reload and login. At this point pfSense is fully operational. Any additional configuration such as firewall rules or DNS overrides can be done from this interface.

VM Intercommunication and Verification

Create VMs as needed. Make sure to attach a VirtualBox Host Only Ethernet Adapter and select the Host Only Network you set up pfSense in.

Set up a web server VM with a static IP and a test page to verify host-to-VM communication.

Set up a client VM in the same adapter and network, configured as a DHCP client. Verify that it receives an IP from pfSense.

From the client VM, access the web server using its IP. Verify that VM-to-VM communication works.

Verify internet access from the client VM.

Note that the client VM has only one interface attached - the Host Only Ethernet Adapter with the relevant Host Only Network selected. Through this single adapter, the VM can reach other VMs on the same network, the host, and the internet.

Conclusion

The result is a clean, self-contained lab network: VMs can communicate with each other and the host, have full internet access, and the host requires no permanent configuration changes. pfSense handles routing, DHCP, and DNS entirely within VirtualBox.

This setup works as a solid foundation for any multi-VM lab that needs real network services, making it particularly useful for cybersecurity home labs.

The Superior way to share files over a LAN

Shoban Chiddarth — Fri, 06 Mar 2026 13:18:02 +0000

GitHub: @ShobanChiddarth/openssh-server

You need to send a file to another machine on your network. It should be a solved problem. It is not.

Every method people actually reach for is either insecure, annoying to set up, or leaves something running on your machine long after you needed it. This post is about the one approach that gets all three things right - and it takes about two minutes to set up.

What You're Probably Doing (And Why It's Bad)

Let's go through the common options honestly.

Python HTTP server

python3 -m http.server 8080

Everyone knows this one. It works, and that's roughly where the positives end. Traffic is completely unencrypted. Anyone on the same network can see every byte in transit. There's no authentication - anyone who can reach the port can download anything you're serving.

Netcat

# sender
nc -l 9999 < file.txt

# receiver
nc 192.168.1.x 9999 > file.txt

Same problem. Cleartext, no auth, one shot if you're lucky. It's basically a raw pipe over TCP dressed up as a tool.

Installing openssh-server on your machine

This one at least solves the encryption problem. But now you've installed a permanent service on your host OS. sshd is running all the time, listening on port 22, attached to your actual system - its users, its filesystem, its everything. You wanted to share one folder for five minutes. You now have a permanently expanded attack surface.

And if you give the other person SSH credentials? They have a shell into your real machine. Full access. That's a lot of trust for a quick file transfer.

Samba / NFS

Heavy to configure, plenty of surface area, and definitely not something you spin up for a quick transfer and tear down cleanly.

The Actual Problem

The core issue with all of these is that they either skip encryption entirely, or they go too far in the other direction and give the other party more access than a file transfer requires.

What you actually want is:

Encrypted transfer
Auth (so not just anyone on the LAN can connect)
Access scoped to exactly one directory, nothing else
Zero footprint when you're done

The Solution: OpenSSH Inside a Docker Container

Here's the idea: run an SSH server inside a Docker container. Mount only the specific directory you want to share into that container. The other party connects over SSH, lands in that directory, and that's all they can see - not your home folder, not your system files, not anything else on your machine. When the transfer is done, you stop the container and it's completely gone.

The host OS never has sshd installed. No permanent service. No lingering open port. The container is the entire blast radius.

I built and published this as a ready-to-use Docker image with two variants: one based on Alpine Linux (smaller, recommended) and one based on Ubuntu Noble. The image handles user creation, password setup, and public key injection entirely through environment variables.

How It Works

When the container starts, the entrypoint script does the following:

Reads SSH_USER, SSH_PASSWORD, and SSH_PUBLIC_KEY from environment variables
Creates a low-privilege user inside the container with those credentials
Writes the public key to that user's ~/.ssh/authorized_keys
Starts sshd in the foreground

The user's home directory inside the container is whatever you bind-mount from your host. They can read and write files there. That's the full extent of what they can touch.

Step-by-Step: Running It

Prerequisites: Docker installed and running. That's it.

1. Pull the image

docker pull shobanchiddarth/openssh-server:alpine-1.0.0

Or if you prefer the Ubuntu variant:

docker pull shobanchiddarth/openssh-server:ubuntu-noble-1.0.0

2. Create the directory you want to share

mkdir -p /tmp/myshare

Put whatever files you want to transfer in here, or leave it empty for the other party to upload into.

3. Set up your environment variables

Grab the sample.env from the repo and copy it:

cp sample.env .env

Edit .env:

SSH_USER=USERNAME
SSH_PASSWORD=PASSWORD
SSH_PUBLIC_KEY=ssh-ed25519 AAAA... you@yourmachine

SSH_PUBLIC_KEY is optional in practice - if the other party doesn't have a key pair, they'll just use the password. But public key is always preferable.

4. Run the container

docker run -d \
  --name myshare \
  -p 0.0.0.0:2222:22 \
  --env-file .env \
  -v /tmp/myshare:/home/USERNAME \
  shobanchiddarth/openssh-server:alpine-1.0.0

The -v flag is the key part. /tmp/myshare is the folder on your machine. /home/USERNAME is where the SSH user lands inside the container. Those two are linked - anything written to one appears in the other. The username in the path should match SSH_USER in your .env.

Your LAN IP is whatever ip a (Linux) or ipconfig (Windows) shows for your network interface - typically something like 192.168.1.x.

5. Transfer files from the other machine

# Upload a file
scp -P 2222 /path/to/file.txt USERNAME@192.168.1.x:~/

# Download a file
scp -P 2222 USERNAME@192.168.1.x:~/file.txt ./

# Interactive session
sftp -P 2222 USERNAME@192.168.1.x

This works from Linux, macOS, and Windows (via PowerShell with OpenSSH, WSL, or Git Bash - all ship with scp and sftp).

6. Tear it down

docker stop myshare
docker rm myshare

Port closed. No service running. Nothing left behind.

Windows Host Note

If you're running Docker Desktop on Windows, the volume mount path uses Windows-style paths:

docker run -d `
  --name myshare `
  -p 0.0.0.0:2222:22 `
  --env-file .env `
  -v C:\Users\YourName\myshare:/home/USERNAME `
  shobanchiddarth/openssh-server:alpine-1.0.0

Everything else - the scp/sftp commands from the client side - is identical.

Security Properties at a Glance

Property	Behavior
Encryption	SSH - all traffic encrypted in transit
Authentication	Password + public key
Host filesystem	Completely inaccessible from inside the container
Shell access	Scoped to the container only
Host SSH daemon	Never installed
Persistence after use	Zero - stop the container, it's gone

One thing worth being explicit about: bind the port to 0.0.0.0 only on trusted networks. That makes the container reachable on all your local interfaces. If you want to lock it down to a specific interface, replace 0.0.0.0 with that interface's IP (e.g., 192.168.1.5:2222:22). Either way, don't forward port 2222 through your router - this is a LAN tool.

Why This Is Better

The Python HTTP server is convenient. This is only marginally less convenient - one docker run command instead of one python3 command - and in exchange you get encryption, authentication, proper access scoping, and a completely clean teardown.

If you have Docker, there's no good reason to reach for the HTTP server anymore.

The repo has both Alpine and Ubuntu variants, a sample.env template, and full usage documentation. Pull it, try it, and stop sharing files over cleartext.

The `known_hosts` problem

Let's say you want your friend to share a file to you. So you ask him his public ssh key and spin up a container with port and volume mapped. And then he tries to ssh into your container. Then he gets hit with this

ssh test@192.168.1.2
The authenticity of host '192.168.1.2 (192.168.1.2)' can't be established.
ED25519 key fingerprint is SHA256:9d8pzTNQ1vLi2laKIqHnzOG+QdgNv8bDQVz67sNJi1E.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

This is the unknown host warning, it is what ssh usually does to make sure you are accessing the machine you think you are accessing by showing the host key of the machine. So since your friend knows he is accessing your machine and trusts is, he types yes and then the host key gets added to ~/.ssh/known_hosts file. He then finishes the file sharing work and then closes the connection so you stop the container and delete it. Some time later if he wants to do another file sharing work, you spin up another container and if you are in the same LAN with the same private IP, ssh client on his machine sees your host with a different ssh host key when he is trying to access it. So it prints a message like this

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:s9QoffY4cHer0u66A9s57WzN3/ufOfCBGTq/v9fhr5w.
Please contact your system administrator.
Add correct host key in /home/mint/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/mint/.ssh/known_hosts:3
  remove with:
  ssh-keygen -f '/home/mint/.ssh/known_hosts' -R '[192.168.56.1]:2222'
Host key for [192.168.56.1]:2222 has changed and you have requested strict checking.
Host key verification failed.

But this can be ignored since it is true that the host key has changed and he has to remove the old known hosts entry with

ssh-keygen -f '/home/mint/.ssh/known_hosts' -R '[192.168.56.1]:2222'

as said in that message. If it is unsure whether or not SOMEONE is doing SOMETHING NASTY you should send your host key to your friend and ask him to compare. You can do it by

docker exec -it myshare /bin/sh # or /bin/bash if ubuntu
cd /etc/ssh
ls *host*.pub # to see the host public key names
ssh-keygen -lf ssh_host_ecdsa_key.pub 
ssh-keygen -lf ssh_host_ed25519_key.pub 
ssh-keygen -lf ssh_host_rsa_key.pub

Now send the output of the last 3 commands to him and tell him to enter the fingerprint of the algorithm (ecdsa or ed25519 or rsa) he is seeing in his screen and if it matches the host will be added to known_hosts (with the current host public key, so he will have to remove it later by following the above instructions) and the connection will happen.

GitHub: @ShobanChiddarth/openssh-server

Setting Up Pi-hole as a Custom DNS Server on my Home Lab

Shoban Chiddarth — Wed, 04 Mar 2026 14:14:02 +0000

Introduction

I'm building out a home lab and this post covers setting up Pi-hole as a custom DNS server so that internal hosts are reachable by name rather than IP address.

This is part of my Physical Network Engineering Home Lab series where I document building and configuring a physical home lab from scratch.

Reason for Choosing Pi-Hole as a custom DNS server

I needed a local DNS server where I could register internal hostnames and have them resolve across the network — so my server is reachable as server.local rather than 192.168.1.2. This becomes especially important as I add more services to the lab.

Pi-hole fits this requirement well. It is primarily a network-level DNS server that supports custom local DNS records, and it comes with a clean web interface for managing them. The fact that it also blocks ads and trackers at the DNS level for every device on the network is a useful side effect — the FBI has even recommended ad blockers as protection against malvertising scams, so having this enforced network-wide without configuring each device individually is a reasonable security baseline.

Setting up Pi-Hole

Pre-requisites

Refer my Physical Network Engineering Home Lab to understand what I already have and working with.

Installing Pi-Hole software on my server

My server runs headless Linux Mint, which is Ubuntu-based and officially supported for Pi-hole.

So I am going to manually download the installer and run it on my server.

wget -O basic-install.sh https://install.pi-hole.net
sudo bash basic-install.sh

The usual install process begins, and I get asked about choosing upstream DNS server.

I went with cloudflare, selected the default ad blocklist, enabled query logging, selected "show everything" because I am the only one using this home lab so there are no privacy issues, and waited for it to finish installing.

The installation is now complete and I get this popup

Post-installation

Pi-hole installs a web interface under /var/www/html/admin. I confirmed it was there after installation.

I visited my server's IP 192.168.1.2 on the browser and it worked fine, like usually.

I tried to access the admin panel at 192.168.1.2/admin and got a 403 error.

Then I remembered the admin panel works only over https. So I tried visiting https://192.168.1.2/admin and it never worked. So I came back to the terminal where I have ssh-ed into the server and ran ss -tulnp | grep :443 to check if the service was running, and the service was indeed running on 0.0.0.0 which means it is supposed to be accessible from the other hosts. That is when I remembered I enabled ufw and had to allow certain ports in the firewall.

I referred the pi-hole docs for the ufw commands and ran the following snippet in the terminal

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 53/tcp
sudo ufw allow 53/udp
sudo ufw allow 67/tcp
sudo ufw allow 67/udp
sudo ufw allow 123/udp
sudo ufw allow 546:547/udp

(Future me here, I just realised I don't need to allow port 67 as I did not setup DHCP server on the pi hole).

Now that I have allowed the ports, I tried visiting https://192.168.1.2/admin/ and got this warning, which I will be taking care of in the next part of my home lab series where I properly configure SSL and get HTTPS on browsers with no warning.

I clicked on "Proceed" and got the pi-hole admin login page, then I entered my admin password I got from the "Installation over" popup and logged in. Now I get this beautiful dashboard.

Note: You can change the default password by running pihole setpassword on the pi hole server.

Pointing Router's DHCP to use pi-hole as DNS

I opened my Tenda router's login page via its IP, went to "Internet Settings" and set the DHCP server to 192.168.1.2

Then I went into System Settings -> LAN settings and did the same

To refresh the DNS server config from the DHCP configuration, I manually turned off the wifi from my laptop and turned it on again.

The DNS server shows up as 192.168.1.2

Verifying Ad blocking at Network level

I checked if the DNS service was working, for both allowed and blocked hosts.

gray@OMEN-Slim-Gaming-Laptop-16:~$ nslookup google.com
Server:     127.0.0.53
Address:    127.0.0.53#53

Non-authoritative answer:
Name:   google.com
Address: 142.251.222.78
Name:   google.com
Address: 2404:6800:4009:80b::200e

gray@OMEN-Slim-Gaming-Laptop-16:~$ nslookup ad-assets.futurecdn.net 
Server:     127.0.0.53
Address:    127.0.0.53#53

Non-authoritative answer:
Name:   ad-assets.futurecdn.net
Address: 0.0.0.0
Name:   ad-assets.futurecdn.net
Address: ::

gray@OMEN-Slim-Gaming-Laptop-16:~$

It works perfectly fine. Ads are blocked in the network level.

Side note: If you are using Cloudflare WARP for privacy, all your internet traffic, including DNS queries are routed through Cloudflare's servers which means the DNS lookup never reaches your Pi-hole and the advertisements domains will be rendered fine. So if you want to access your home lab's hosts using DNS resolution from pi hole or any other DNS server or network level ad blocking for devices where cloudflare warp is not available, you must temporarily turn off Cloudflare WARP.

Setting Up Custom DNS records

pi.hole is a custom DNS entry in pi-hole by default and it works.

I want to add my own DNS records and check them, which is the entire purpose of this project. So I wanted another host with static IP on the same LAN.

Virtualbox VM with static IP in the LAN

I cloned an existing Mint VM, selected to create random MAC addresses for each interface and set it's network adapter to "Bridged" and bridged it with the real interface I use to connect to the LAN, and set "Promiscuous Mode" to allow all. For more information on Virtualbox networking see Virtualbox Manual - Chapter 6 : Virtual Networking.

When I booted it up, it had DHCP by default.

I went to settings and changed it to static IP 192.168.1.23 and turned the interface off and turned it on again and the static IP is available and accessible from the host as well as the server. I also turned off automatic DNS as DHCP will be disabled and manually added 192.168.1.2 as the DNS server.

Adding a custom DNS record in pi hole web GUI

I went to Pi hole admin page -> settings -> Local DNS records and added this entry

Side Note: I want this to be temporary that is why I didn't bind DHCP reservation to MAC address in the router.

Testing the Custom DNS record

DNS query works from both my laptop and the server. So I set up a nginx web server in the VM like usually

sudo apt-get update
sudo apt-get install nginx -y
sudo systemctl enable nginx --now

And edited the default index.html file.

Nginx web page as well as pinging is working from my laptop

as well as the server.

Changing default website on the pi-hole DNS server (not required)

This is the new website hosted on the root folder of the DNS server.

Minor Issues encountered

Cloudflare WARP conflict (as mentioned above)
Do not use a custom domain with TLD as .local because all .local domains are first processed through the host before sending it anywhere else and it is used for mDNS (multicast DNS, for when hosts need to discover each other without a central DNS server)
Make sure to allow the required ports in your firewall as mentioned above
Every client that is connected to the LAN and is using DHCP has to refresh by disconnecting and reconnecting for this update to work.

CONCLUSION

I have successfully setup pi-hole on an Ubuntu-based server for network wide ad blocking as well as local DNS resolution.

After this, I am going to set up fully local SSL for HTTPS (without browser warnings) on my physical network engineering home lab. I will also document setting up pi-hole in docker as well as a Virtualbox VM as a portable alternative when this pi-hole server is inaccessible.

How to clone all GitHub repos of multiple users at once?

Shoban Chiddarth — Thu, 26 Feb 2026 15:58:52 +0000

Repo Link

This script helps you clone all repositories of a given list of GitHub users (including organizations) at once, instead of cloning them manually one by one.

I built it after running into the need to archive and collect repositories from multiple accounts efficiently. The goal was simple: automate bulk cloning in a clean, repeatable way.

What It Does

Accepts multiple GitHub usernames
Fetches all accessible repositories via the GitHub API
Clones them into a structured local directory
Supports shallow clone (--depth 1) or full history
Skips repositories that are inaccessible or already cloned

Each user gets their own folder inside the target directory.

Requirements

Python 3.12+
git installed and available in PATH
A GitHub Personal Access Token with read access to repository contents

Setup

Generate a Personal Access Token:
- Go to GitHub → Settings → Developer settings → Personal access tokens
- Create a token with repository read access
Copy sample.env to .env
Replace the placeholder token value with your actual token
Install dependencies:

   pip install -r requirements.txt

Usage

Run:

python github-main.py

You’ll be prompted for:

A space-separated list of GitHub usernames
A target directory (default: mass_clone_output)
Clone depth (None for full history or 1 for latest commit only)

The script validates usernames, fetches repositories, and clones them sequentially with live git clone output shown in the terminal.

Repository

How to Enable MAC Address Randomisation in Linux Desktop

Shoban Chiddarth — Sat, 14 Feb 2026 17:01:13 +0000

Link to Project: https://github.com/ShobanChiddarth/randomised_mac_linux

Why a Persistent MAC Address Is a Problem

A persistent hardware address allows networks to consistently identify the same device across sessions. On:

Public Wi-Fi
Campus networks
Enterprise environments
Captive portals

this makes long-term tracking trivial, even if your IP address changes.

Many Linux desktops still use the permanent hardware address by default, which means your device can be passively identified every time it reconnects to a network.

How This Project Solves It

This project automates MAC address randomisation at boot.

On every system startup:

The interface is brought down
A new locally administered MAC address is generated
The interface is brought back up

A systemd service ensures this runs automatically, requiring no manual action after setup.

Installation

When you install macchanger, you may get a prompt to enable regular changing of MAC addresses. You should select "no" because we wan't complete control over when and how the MAC address randomisation is scheduled.

Debian based

Save this script and run it as sudo

sudo apt install macchanger git -y
git clone https://github.com/ShobanChiddarth/randomised_mac_linux.git
cd randomised_mac_linux
chmod +x ./randomise_MACs.sh
sudo cp randomise_MACs.sh /usr/bin/
sudo cp randomise_MACs.service /etc/systemd/system/
sudo systemctl daemon-reload
sudo systemctl enable randomise_MACs

Now your MAC addresses of real network interfaces will automatically change to a random value on each boot. To verify it, you can run ifconfig to show MAC addresses before and after running sudo systemctl start randomise_MACs to compare values.

Other distros

Visit the GitHub repo and google your distro specific command for each command listed.