In order to combat having to manual input new users for the active directory within samba. The Lab committee has decided that it would be in our best interest to automate the registration process with a full-stack like app. Below is how the processes would be handled.

The frontend of this project would be handled in collaboration with the Spider Committee. We're expecting this to look something like a standard login page with an option to register an account. Using a system of forms in the frontend which would be sent to an API, and within that API would be the library of functions which would interact with our backend Samba AD LDAP.

On the 1337.berkeley.edu site, the rough idea is a request would be sent with a POST request to the API including (but not limited to) the following fields:

1. Username
2. Password
3. Berkeley email
4. Berkeley ID

Following a two-step verification by checking the Berkeley ID against Berkeley's public API (using ocflib), then sending an email to the submitted berkeley.edu email address, we will know for certain that the email originates from a Berkeley student. Additionally, after the user has successfully registered an account, they can return to the original login page and instead of clicking “register new account”, they can use their registered credentials to login and change various attributes we allow them to through a new set of forms corresponding to the Samba AD LDAP schema. Some of these attributes can include a profile picture, preferred first name and last name, username, etc.

As we're currently using Astro for the 1337.berkeley.edu website, we except this systems of forms to be completed in Javascript, so some familiarity with the framework and the programming language would be ideal, but not mandatory.

Given Samba AD's “samba-tool” program is written in Python and the ocflib library used for verifying Berkeley student accounts is also written in Python, it makes sense to write our component library in Python as well, plus its accessible and most people coming from the CS department know it. Familiarity with LDAP concepts, usage of ldapmodify, ldapsearch, and ldif files is also a good to know as it'll be our primary means of adding, modifying, and deleting entries in the Samba AD LDAP.

As an overview, the goal in the backend of the user registration project is to mimic the functionality of Samba AD's “samba-tool”, the program which is used in the terminal on Domain Controller (DC) nodes on a Samba connected network of hosts to add users, change records, modify security principles, and so on. Our goal is to re-create the user addition and modification functionalities. In addition to our goal is to avoid having an API running on top of a very privileged DC exposed to the internet through the frontend, as it leaves a pretty valuable attack surface exposed. By implementing a function of libraries interacting directly with the Samba's LDAP instead of going through “samba-tool”, we are able to implement various security considerations and avoid running said function as a subprocess of the API.

Such security considerations include:

• Input sanitization
• Fine tuning of the scope of interactable LDAP
• Implementation of other libraries such as ocflib

The process would go something like this:

1. User clicks “register account” on the frontend
2. User inputs the form details as specified in the frontend section
3. The API endpoint receives a form of details and begins parsing, checking each value in the form for malicious code such as LDAP injections, python scripts, bash scripts, and more.
4. Once the values are vetted, send a two-step verification to the user's Berkeley email address.
5. Once verified, submit the processed user data to the Samba AD LDAP via LDIF file, where their account will be created in the Samba AD, usable across all the AD connected services.

!! An extra detail, because of how our AD is setup, new users are given the userPrincipalName suffixed with “ad.1337.berkeley.edu” when it should be “1337.berkeley.edu”. When writing new users to the LDAP, ensure that after they are added their userPrincipalName is adjusted accordingly.

Microsoft did a pretty good job documenting their logic as it interacts with Windows AD as it follows RFC2251. Samba, our authentication backend, is designed to be a drop-in replacement for Windows AD and follows much of the same requirements of user presence in the LDAP. By mimicking the logic as documented here as well as the RFC2251 requirements for LDAP interaction, producing an suite of tools such as a library or package to interact the same ways internal tools like samba-tool would be the right direction for this project. Once this set of tools are developed, implementing them in an API so it can provision new users remotely without needing direct Domain Controller access would be the next step.