Sysadmin Documentation/iron

< Sysadmin Documentation
Revision as of 00:30, 20 May 2017 by Azhao (talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Return to Server Setup

Iron is the LDAP server.


Dell Poweredge 1850, dual Xeon 3.2GHz, 6GB RAM, 2x 150GB drives.


  • LDAP server
  • RADIUS server


Iron only needs slapd to provide directory services. The configuration is in /etc/ldap/slapd.conf.

LDAP is a mostly standard setup using slapd.conf (as opposed to cn=config). It has several custom indexes in addition to special ACL's which require TLS/SSL connections.

We will need to replace the LDAP certs (right now they are wildcard self-signed).

Description of our LDAP stuff

This shit will only make sense if you know a little bit about ldap. read a few books about ldap and absorb for a few years, then read this

Our ldap structure should mostly make sense after looking at our custom schema here, but there is more that's not in there. The OID used in our custom schema is a real one registered somehow that we got somehow.

Each UGCS user consists of 3 seperate object classes. The standard posixAccount and shadowAccount used to provide the necessary information for nis, and custom ugcsUser objectClass. The ugcsUser is the "structural" objectclass, and the posixAccount and shadowAccount are auxiliary.

We use a custom schema for our UGCS users, because the standard ldap "person" adds on a lot of useless attributes that we don't want, with shit like "surname" that's mandatory. yuck.

Our standard attributes are all used exactly according to the official ldap standard. To note is that cn is the user's full legal name, and uid is the user's username. Also importantly, we use the uid as the attribute in the dn.

Description of our custom attributes:

  • ugcsMail - This attribute should always be {uid} It exists for ldap integrations that ask for an email address
  • ugcsExtMail - This attribute is used for password resets
  • ugcsAlias - email addresses that the user can receive on. Any mails sent to the mail server that match any address here will go to that user

Users are in ou=users,dc=ugcs...

In addition to users, we also have posix groups. These groups are all just the posixGroup objectClass. Unlike the posixAccount, in the posixGroup, cn is the name of the group. Very confusing.

For standard linux-y behavior, each user has their own matching group. Additionally, we have a sysadmins posix group that gives its members ssh and sudo access where necesary.

in ou=ldap,dc=ugcs... we have some other shit that's needed.

We have 2 LDAP groups used to control ACL to reading and writing to ldap by users. There is the sysadmins groupOfNames and the ugcs_users groupOfNames. Sysadmins gives read/write control over the ldap, while users just gives read access.

Additionally we have some service accounts just dumped in here. These service accounts are for integrations that need to access the ldap. [document those integrations here]


Q: Why are you using LDAP, not sql or something

A: Because LDAP has lots of out of the box integrations with various services. I'd rather store the data in tables, but basically all the shit we SSO with has an out of the box ldap integration.

Q: Why are you using openldap, not some other ldap

A: because it's free and there's a package for it. idk 389 ds looks pretty okay, but we're using openldap

Q: What about the OLC?

A: it's fucking retarded. It's not human readable, and not puttable in source control.

radius shit

This shitass shit isn't what we're using but it's close enough. TODO: make it for ldap. We can make wifi and shit with this.

freeradius server as the backend. This offers direct radius-ness when needed, and support for other things (like pam). The main downside is shit documentation

The server is installed using debian packages, postgresql freeradius freeradius-postgresql

We use the instructions in the freeradius howto guide for setup

Setting up the RADIUS database

First, you should create a new empty 'radius' database in SQL and a database user with permissions to that database. You could of course call the database and the user anything you like but you probably should stick with 'radius' for both to keep things simple.

Next up, you need to create the schema for your database. There is an SQL script file for each SQL type in doc/examples/ in your operating system's doc directory (or where you untar'd FreeRADIUS). On SUSE this is under /usr/share/doc/packages/freeradius/

Create PostgreSQL Database

su - postgres
createuser radius --no-superuser --no-createdb --no-createrole -P
createdb radius --owner=radius

Note: choose a secure password when prompted for one by the createuser command.

cd /usr/share/doc/packages/freeradius/doc/examples/
psql -U radius radius 

For the debian the sql files are in /etc/freeradius/sql Since postgres default settings are peer for local, we connect over host to run the thing. We also want to like actually run the schema file

psql -h -a -f schema.sql -U radius radius

Next we enable the include sql.conf in the radiusd.conf file. Then fill in the appropriate database type and credentials in sql.conf. We'll also enable stripped usernames in the /etc/freeradius/sql/postgresql/dialup.conf file

now we enable this shit in the auth part. We're just going to not do the optional stuff for now but maybe l8r.

Edit /etc/raddb/sites-available/default and uncomment the line containing 'sql' in the authorize{} section. The best place to put it is just after the 'files' entry. Indeed, if you'll just be using SQL, and not falling back to text files, you could comment out or delete the 'files' entry altogether.

Additionally, edit /etc/raddb/sites-available/inner-tunnel and uncomment the line containing 'sql' under "authorize {}". See below.

Also uncomment the line saying 'sql' in the accounting{} section to tell FreeRADIUS to store accounting records in SQL as well.

Optionally add or uncomment 'sql' to the session{} section if you want to do Simultaneous-Use detection.

Optionally add or uncomment 'sql' to the post-auth{} section if you want to log all Authentication attempts to SQL.

now we change the shared secret. This is kind of improtant. It's in client.conf