welcome: please sign in

Diff for "PrincipalsForNonHumans"

Differences between revisions 7 and 8
Revision 7 as of 2012-03-25 06:06:43
Size: 2433
Editor: ClintonEbadi
Comment:
Revision 8 as of 2013-01-11 08:52:51
Size: 3633
Editor: ClintonEbadi
Comment: at least mark misleading content, try to explain what create-service-user does
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
Creating the basis of an account for a non-human user that provides a shared service is automated through a shell script (UserManagement).

The automated process creates a kerberos principal with a random key and an afs home directory for the user. You will need to manually extract the keytab to the appropriate notes, and update any configurations to use the principle as needed.

The process of creating a service key (e.g. `postgres/$host.hcoop.net`) is not automated. Follow the GSSAPI documentation of the appropriate service.

== General Service Account ==

''TBD, general processes for generic services accounts that don't need to do things like serve websites''

== System Service Account ==

''TBD: process for things like postgresql, ssh, ... that use a traditional MitKerberos service/$host principal to allow GSSAPI auth''

== Web Service Account ==

''TBD: process for accounts that will run cgis, usually controlled by the hcoop user via domtool, and that can never log in''

= Obsolete Info =

Some of these things may be actively misleading, proceed with caution. This is being kept around to aid in writing the improved documentation above.
Line 66: Line 88:
CategorySystemAdministration CategoryOutdated CategorySystemAdministration CategoryNeedsWork CategoryOutdated

Creating the basis of an account for a non-human user that provides a shared service is automated through a shell script (UserManagement).

The automated process creates a kerberos principal with a random key and an afs home directory for the user. You will need to manually extract the keytab to the appropriate notes, and update any configurations to use the principle as needed.

The process of creating a service key (e.g. postgres/$host.hcoop.net) is not automated. Follow the GSSAPI documentation of the appropriate service.

1. General Service Account

TBD, general processes for generic services accounts that don't need to do things like serve websites

2. System Service Account

TBD: process for things like postgresql, ssh, ... that use a traditional MitKerberos service/$host principal to allow GSSAPI auth

3. Web Service Account

TBD: process for accounts that will run cgis, usually controlled by the hcoop user via domtool, and that can never log in

4. Obsolete Info

Some of these things may be actively misleading, proceed with caution. This is being kept around to aid in writing the improved documentation above.

here's the final procedure you should follow (for installing service "SERVICE" (mysql) on host "HOST" (deleuze)):

1. create local user SERVICE in /etc/passwd:

  • (usually already done by Debian postinst scripts in form of "adduser --system SERVICE". (--system ensures that the assigned ID is in range 100 < ID < 1000 .))

2. create Kerberos principal:

kadmin.local -q "addprinc -policy service -randkey SERVICE/HOST"

3. export user's keys to /etc/keytabs/SERVICE.HOST and chmod the file properly:

kadmin.local -q "ktadd -k /etc/keytabs/SERVICE.HOST SERVICE/HOST"
chown SERVICE:wheel /etc/keytabs/SERVICE.HOST
chmod 440 /etc/keytabs/SERVICE.HOST

4. create OpenAFS user SERVICE.HOST

  • (You must make sure that the UID chosen in AFS is above 1000. You can't use UIDs <1000 because those are reserved for local system's IDs, and so such uids in AFS would mess up reported Unix ownership of files).

      pts cu SERVICE.HOST.hcoop.net

5. create OpenAFS group "SERVICE" if it doesn't exist, and add SERVICE.HOST to it:

pts cg SERVICE
pts ad SERVICE.HOST SERVICE

6. modify service's init script in /etc/init.d/ in the following way:

  • Change shell at the top of script to "#!/usr/bin/pagsh.openafs"
  • Change start-stop-daemon invocation in action 'start':

start-stop-daemon --start --pidfile $PIDFILE \
 -c SERVICE:SERVICE \
 --exec /usr/bin/k5start -- -U -b -f /etc/keytabs/SERVICE.`hostname` \
 -K 300 -t -p $PIDFILE \
 <The original start command>
  • Or if the service does not use start-stop-daemon itself, you still use it in
    • action 'start' to run k5start on a line before <The original start command> and later in 'stop' to close it:

      • (start):

start-stop-daemon --start --pidfile /var/run/SERVICE/k5start-SERVICE.pid \
  -c SERVICE:SERVICE \
  --exec /usr/bin/k5start -- -U -b -K 300 -t -p /var/run/SERVICE/k5start-SERVICE.pid \
  -f /etc/keytabs/SERVICE.`hostname`
sleep 2
  • (stop):

start-stop-daemon --stop --pidfile /var/run/SERVICE/k5start-SERVICE.pid
rm -f /var/run/SERVICE/k5start-SERVICE.pid

7. You give permissions in AFS space to group "SERVICE", or to user "SERVICE.HOST" if specific instance is important. (Mostly, you just add permissions to "SERVICE").


CategorySystemAdministration CategoryNeedsWork CategoryOutdated

PrincipalsForNonHumans (last edited 2013-01-11 08:52:51 by ClintonEbadi)