Authentication and Authorization Project

For this project option, you will implement a central authentication and authorization server using MIT Kerberos and OpenLDAP. This implementation will run inside an Alpine Linux virtual machine using QEMU for virtualization. A second Alpine Linux virtual machine will function as a client system for testing the authentication and authorization server.

Background

Whenever an enterprise has multiple systems, it is desirable to allow users to use the same credentials to access each system. For example, at Coastal Carolina University, you have one username and password that permits access to a wide variety of different systems, from registration, to Moodle, to accessing protected content at the library. This single set of credentials is actually stored on a central authentication and authorization server, and each system that needs to authenticate and authorize users connects to that server.

There are several integrated authentication and authorization servers on the market, with Microsoft Active Directory likely the most popular. However, an authentication and authorization server can be implemented on a much smaller budget using the same components that make the commercial servers work: Kerberos authentication and some kind of directory server that stores information about the users. Authorization rules are created based on the information stored in the directory server.

Since the authentication and authorization server is accessed frequently, lookups need to be fast. For this reason, a relational database (like MySQL, MariaDB, or Postgresql) is not used. Instead, we use a hierarchical database that makes structured information retrieval efficient. The industry standard is to use the Lightweight Directory Access Protocol (LDAP) for this purpose.

Thus, all we need for a central authentication and authorization server is Kerberos plus an LDAP server. Kerberos handles the authentication (by checking passwords for users), while the LDAP server provides the authorization information. There are several implementations of Kerberos available, but original MIT Kerberos is the one I’d recommend. Similarly, multiple LDAP servers are out there, but OpenLDAP is the one I would choose for this purpose.

The main challenge with this project is learning how Kerberos and OpenLDAP work, then setting up both servers and getting them to work together. Some of the following resources might be useful:

• Using QEMU
• Alpine Linux Notes
• iptables Notes
• Configure OpenLDAP - Alpine Linux Wiki - Note that we will only use OpenLDAP for authorization, not authentication
• How to Integrate LDAP and Kerberos
• MIT Kerberos
• OpenLDAP

Project Requirements

A successful implementation of this project:

1. Has two Alpine Linux virtual machines running in QEMU: one client and one server.
2. Has a working Kerberos KDC on the server machine.
3. Has a working OpenLDAP server on the server machine.
4. Has a sensible organization to the LDAP directory tree, in which organizational units are used to contain users and groups.
5. Demonstrates the ability for the client machine to acquire a Ticket Granting Ticket from the server machine by running kinit.
6. Demonstrates the ability to log into the client machine using credentials stored in the Kerberos KDC on the server machine.
7. Has a working doas.conf file on the client machine that permits a user account described in the LDAP tree to run the doas command and become root on the client machine.
8. Has a working firewall on the server VM, with only the ports required for Kerberos and LDAP to work open for incoming connections.

Milestones

Milestone 1

For Milestone 1, prepare a video presentation that covers the following items:

1. Demonstrate that you have two working Alpine Linux virtual machines: the client machine and the server machine.
2. Demonstrate that you can ping the server machine from the client machine, showing that your virtual network is configured properly between the two.

Each person in the group should present for approximately equal time. Be sure to include the URLs to each person’s portfolio in your presentation.

Add the following items to your portfolio:

1. Your current resume.
2. The QEMU arguments you used to connect the server and client machines together.

Milestone 2

For Milestone 2, prepare a video presentation that covers the following items:

1. Demonstrate that you have installed MIT Kerberos and have the KDC up and running.
2. From the server VM, show that you can perform a kinit.
3. From the client VM, show that you can perform a kinit.

Each person in the group should present for approximately equal time. Be sure to include the URLs to each person’s portfolio in your presentation.

Add the following items to your portfolio:

1. A screenshot of the kinit from the client machine.
2. A brief explanation of how MIT Kerberos authenticates a user. Be sure to explain what the Ticket Granting Ticket is, and identify on which end of the connection the TGT is decrypted. Note whether or not the user’s password is ever sent over the network.

Milestone 3

For Milestone 3, prepare a video presentation that covers the following items:

1. Demonstrate that you have OpenLDAP installed with slapd running.
2. Show the LDIF file(s) that you used to configure slapd.
3. Show the LDIF file(s) that you used to add your schema, add organizational units, and add at least one user and group to the tree.
4. Show that the id command can find your LDAP user on the server.

Each person in the group should present for approximately equal time. Be sure to include the URLs to each person’s portfolio in your presentation.

Add the following items to your portfolio:

1. A sample LDIF file showing how to configure slapd.
2. A sample LDIF file showing how to add things to the LDAP directory tree.

Milestone 4

For Milestone 4, prepare a video presentation that covers the following items:

1. Show that the id command can find your LDAP user on the client.
2. Demonstrate that you can log into the client VM using your Kerberos+LDAP username password.
3. Demonstrate that the Kerberos+LDAP user can become root by running doas su -
4. Run the following commands on the server to show your firewall rules:

iptables -S
ip6tables -S

Each person in the group should present for approximately equal time. Be sure to include the URLs to each person’s portfolio in your presentation.

Add the following items to your portfolio:

1. A brief description of your iptables and ip6tables setup, including your firewall rules.
2. A brief description of the project and how you went about implementing it. Include some potential uses for your authentication and authorization server in the description.
3. A statement about teamwork. Think about answers to questions that you might get asked in an interview. For example, how well did you work as part of a team? How did you divide your responsibilities between team members? How did you communicate with your teammates? How did you resolve any conflicts?

Tips

• Create the client and server virtual machines first.
• There are several ways to create a virtual network between your client and server VMs. The easiest is to use QEMU’s built-in “socket” networking, with the server listening on a TCP port and the client connecting to that port. If you use this approach, remember that the server must be started FIRST, since the client can’t connect to the port if the server isn’t already listening. See the QEMU Network options for the required arguments.
• Set up Kerberos on the server first, then get to where you can do a kinit from the server. Once kinit is working on the server, try to get it working on the client.
• After Kerberos is working, work on OpenLDAP. Be sure that you’re using the LDIF files to configure slapd, as opposed to using the deprecated legacy configuration files.
• Think about your LDAP schema. For a top level domain, you can use dc=csci427 (or dc=csci427,dc=coastal,dc=edu if you prefer). Put your user account in one ou, and any group accounts in another.
• For authentication from the client, look for PAM modules that can do Kerberos authentication.
• Authorization on the client side only really needs the OpenLDAP client and nss configured properly. As long as you can see the LDAP user’s name and group using the id command, the LDAP server is probably working.
• Caching is optional, but if you choose to implement a client-side cache, I recommend nscd.
• Ignore anything you see about something called sssd when doing your research. Alpine Linux doesn’t support sssd, and it’s a complete piece of shit anyway.

This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.