Overview Of Project Stellar Access

Project Stellar Access involves setting up DHCP, DNS, and Identity Management servers. First, I’ll install and configure DHCP. Next, I’ll install and configure BIND9. Lastly, I’ll install FreeIPA and create 3 groups each with their own users. Following the setup, I will install three Linux systems, join them to the domain, and verify that the user accounts I created can successfully log in.

Configuring ISC-DHCP

The configuration file I will be configuring is in /etc/dhcp/dhcpd.conf. The subnet I’ll be working with is 192.168.1.0/24. The server will allocate IP addresses from .10 to .254, excluding .1 through .9. The subnet mask and gateway are also configured. For DNS resolution, I’ll be using the IP address of the local BIND server to ensure client machines can do name resolution. I’ll also be using an upstream resolver as my secondary DNS entry.

Configuring BIND9 Conf File

The configuration file I will be working on is in /etc/bind/named.conf.options. I configured the forwarders option to use an upstream resolver, Cloudflare, to handle queries that the local DNS server cannot resolve. The interface with the specified IP address listens on port 53, and all systems within the subnet are permitted to query the server. The DNS server is also capable of performing recursive lookups independently, without relying on an upstream resolver.

Configuring BIND9 Forward Zone

I created a forward zone file called stellar.access.dns, which holds records for forward lookups which map domain names to IP addresses. These records are categorized as forward zones.

I specified that this server is the SOA for the stellar.access domain. The TTL value defined above the SOA will be included in the query response. Any system querying our DNS server will cache the response for one week. The file’s serial number is incremented by one every time the file is modified. The secondary DNS server will check this file weekly for updates. If the secondary server fails to update, it will attempt to do so the following day. In the event that the secondary DNS server cannot communicate with the primary server, it will continue using the forward zone data for 28 days.

Additionally, any system that queries our DNS server and receives a negative response will cache that response for one week. The NS record indicates that this server is authoritative for the domain. I have included the DNS server as an A record, along with the DHCP and other relevant servers. I’ll revisit this file later.

Configuring BIND9 Reverse Zone

Now, I’ll work on getting the reverse zone /etc/bind/1.168.192.in-addr.arpa.dns configured. This file will contain records categorized as reverse zones.This reverse zone file is similar to a forward zone file, however, instead of using A records, it uses PTR records to perform reverse lookups. Notice that i don’t have to specify the full IP address as the DNS server is smart enough to figure it out.

Configuring FreeIPA

FreeIPA configuration is an interactive process. As you can see, the necessary values are being populated, and a Certificate Authority is being created. Once the process continues with these values, components like SELinux, Kerberos, HTTPD, and others will be configured automatically.

Adjusting Firewall Rules

Once the configuration of IPA is done, it will ask to open a few ports on the firewall and copy records to the forward zone. I will be copying those records shortly. I will use a for loop to enable these services on the firewall. Once that is done, we are set.

Adding Records To The Forward Zone

After successfully configuring FreeIPA, I added the records from /tmp/ipa.system.records to the forward zone file.

Creating Groups

Using a for loop, i created the Network Engineers, Help Desk, and Developers group. I created each user filling out information that the account needs. IPA provides a interactive process for this but for the purposes of the account creation, I wanted to show you how it is done.

Joining Computers To The Domain

I have a client machine that i named hd-pc1.stellar.access. There is a reason why the host name includes the stellar.access domain and that is because, issues will arise when joining the computer to the domain. I issued the ipa-client-install —mkhomedir to join the computer to the domain. It discovered the domain and went through the configuration process. As you can see, the IPA server has information about the system.

Signing In With A User Account

Within the hd-pc1.stellar.access system, I signed in with the user chrisortiz.aldana. After successfully signing in, I made sure that the system was fully operational.

Conclusion

I have established a fully functional IT operations environment; however, I will need to take additional steps to implement policies, create a secondary server for high availability, and secure my systems. To recap, I have configured a DHCP server to provide IP addresses, set up a DNS server for name resolution, and implemented a FreeIPA server to manage users and groups. This concludes Project Stellar Access. From here, the sky is the limit! Stay tuned for upcoming projects that will further enhance the functionality of Stellar Access.