SystemAdministration/KerberosAdministration - Revision history

Paulej72: /* Deleting Principles */

2014-07-19T21:44:43Z

Deleting Principles

← Older revision		Revision as of 21:44, 19 July 2014
Line 94:		Line 94:
	=== Deleting Principles ===		=== Deleting Principles ===

	Deletion is done with the ~~delete_principle~~ command. This will cause tickets to fail to validate, and for hosts, require a new keytab be generated. This shouldn't be a frequent operation		Deletion is done with the delete_principal command. This will cause tickets to fail to validate, and for hosts, require a new keytab be generated. This shouldn't be a frequent operation

	== Creating keytabs ==		== Creating keytabs ==

62.194.147.98: /* Resetting a users password */

2014-03-29T16:03:17Z

Resetting a users password

← Older revision		Revision as of 16:03, 29 March 2014
Line 64:		Line 64:
	</pre>		</pre>

	=== Resetting a ~~users~~ password ===		=== Resetting/changing a password ===

	'''change_password martyb'''		'''change_password martyb'''

62.194.147.98 at 16:02, 29 March 2014

2014-03-29T16:02:35Z

@@ Line 62: / Line 62: @@
 kadmin:  q
 root@helium:/root#
 </pre>

68.174.178.60: /* Creating keytabs */

2014-03-28T04:36:28Z

Creating keytabs

← Older revision		Revision as of 04:36, 28 March 2014
Line 87:		Line 87:
	keytabs, as described above can allow something to generate a kerberos ticket without a password. They can be used with the kinit command in shell scripts to do single-sign on.		keytabs, as described above can allow something to generate a kerberos ticket without a password. They can be used with the kinit command in shell scripts to do single-sign on.

	<pre>kinit -k -t $KEYTAB $USER</pe>		<pre>kinit -k -t $KEYTAB $USER</pre>

	They're generated by a kerberos admin with the ktadd command		They're generated by a kerberos admin with the ktadd command
Line 93:		Line 93:
	<pre>kadmin: ktadd -k filename *principle</pre>		<pre>kadmin: ktadd -k filename *principle</pre>

	Treat these like SSH private keys, and read only to the user that can access it.		Treat these like SSH private keys, and read only to the user that can access it.

	== KRB5 Replication ==		== KRB5 Replication ==

	TBD, I have it semi-working, but replication disabled. Document it when its fully setup		TBD, I have it semi-working, but replication disabled. Document it when its fully setup

68.174.178.60 at 02:58, 28 March 2014

2014-03-28T02:58:12Z

← Older revision		Revision as of 02:58, 28 March 2014
Line 82:		Line 82:

	Deletion is done with the delete_principle command. This will cause tickets to fail to validate, and for hosts, require a new keytab be generated. This shouldn't be a frequent operation		Deletion is done with the delete_principle command. This will cause tickets to fail to validate, and for hosts, require a new keytab be generated. This shouldn't be a frequent operation

			== Creating keytabs ==

			keytabs, as described above can allow something to generate a kerberos ticket without a password. They can be used with the kinit command in shell scripts to do single-sign on.

			<pre>kinit -k -t $KEYTAB $USER</pe>

			They're generated by a kerberos admin with the ktadd command

			<pre>kadmin: ktadd -k filename *principle</pre>

			Treat these like SSH private keys, and read only to the user that can access it.

	== KRB5 Replication ==		== KRB5 Replication ==

	TBD, I have it semi-working, but replication disabled. Document it when its fully setup		TBD, I have it semi-working, but replication disabled. Document it when its fully setup

68.174.178.60: /* Keytabs */

2014-03-28T02:54:52Z

Keytabs

← Older revision		Revision as of 02:54, 28 March 2014
Line 20:		Line 20:
	=== Keytabs ===		=== Keytabs ===

	Keytabs are used for host-to-host authetication and preauthorization. ~~For~~ the ~~most part~~, ~~all you need~~ to ~~know is~~ a ~~host needs to have its own key in its keytab~~. ~~If you following~~ the ~~new host instructions~~, ~~this was done during KRB5 setup~~.		Keytabs are used for host-to-host authetication and preauthorization. They act as the kerberos equivelent of SSH keys, with the advantage that they can be generated on demand. Both users and hosts can have keytabs, and they can be specified to kinit to generate a ticket without passwords. This is extremely useful for cronjobs running across the network (backup and icinga), as we can easily nuke the account by blowing away the kerberos principle. We should never use SSH private keys internally; kerberos is easier to manage, and it validates rdns as it goes in an attempt to help prevent spoofing attacks.

	== kadmin ==		== kadmin ==

68.174.178.60: /* What Is Kerberos */

2014-03-28T02:50:22Z

What Is Kerberos

← Older revision		Revision as of 02:50, 28 March 2014
Line 5:		Line 5:
	Kerberos is a single-sign on service. When a user is autheticated by kerberos, they can access all kerberosized services without having to re-autheticate. This allows for things like node-to-node scps to work without having to deal with setting up per user public/private keys. The main unit in kerberos is the principle, which is simply an account which tickets can be issued for. Users and hosts have kerberos accounts to autheticate with themselves and other nodes across the network. Tickets are granted to users which are handed to kerberosed services to facility authetication.		Kerberos is a single-sign on service. When a user is autheticated by kerberos, they can access all kerberosized services without having to re-autheticate. This allows for things like node-to-node scps to work without having to deal with setting up per user public/private keys. The main unit in kerberos is the principle, which is simply an account which tickets can be issued for. Users and hosts have kerberos accounts to autheticate with themselves and other nodes across the network. Tickets are granted to users which are handed to kerberosed services to facility authetication.

	As of writing, the only kerberosized ~~service~~ we're running is SSH.		As of writing, the only kerberosized services we're running is SSH and Apache. icinga uses kerberosized ssh to access other nodes for status information.

	== Kerberos Teminology ==		== Kerberos Teminology ==

Xlefay: /* Creating hosts */

2014-03-24T03:25:50Z

Creating hosts

← Older revision		Revision as of 03:25, 24 March 2014
Line 69:		Line 69:
	See the node setup guide for a more in-depth instructions. Creating a host principle is similar to a user except we generate a random password (which isn't used for anything since hosts use keytabs), then generate a keytab. You must be root to write the keytab file		See the node setup guide for a more in-depth instructions. Creating a host principle is similar to a user except we generate a random password (which isn't used for anything since hosts use keytabs), then generate a keytab. You must be root to write the keytab file

	'''add_principal -randkey host/carbon.li694-22@LI694-22''' - '''ktadd host/carbon.li694-22@LI694-22'''		'''add_principal -randkey host/carbon.li694-22@LI694-22'''
			'''ktadd host/carbon.li694-22@LI694-22'''

	<pre>kadmin: add_principal -randkey host/carbon.li694-22@LI694-22		<pre>kadmin: add_principal -randkey host/carbon.li694-22@LI694-22

Xlefay: /* Creating hosts */

2014-03-24T03:25:06Z

Creating hosts

← Older revision		Revision as of 03:25, 24 March 2014
Line 69:		Line 69:
	See the node setup guide for a more in-depth instructions. Creating a host principle is similar to a user except we generate a random password (which isn't used for anything since hosts use keytabs), then generate a keytab. You must be root to write the keytab file		See the node setup guide for a more in-depth instructions. Creating a host principle is similar to a user except we generate a random password (which isn't used for anything since hosts use keytabs), then generate a keytab. You must be root to write the keytab file

	~~<pre>kadmin:~~ '''add_principal -randkey host/carbon.li694-22@LI694-22'''		'''add_principal -randkey host/carbon.li694-22@LI694-22''' - '''ktadd host/carbon.li694-22@LI694-22'''

			<pre>kadmin: add_principal -randkey host/carbon.li694-22@LI694-22
	WARNING: no policy specified for host/carbon.li694-22@LI694-22; defaulting to no policy		WARNING: no policy specified for host/carbon.li694-22@LI694-22; defaulting to no policy
	add_principal: Principal or policy already exists while creating "host/carbon.li694-22@LI694-22".		add_principal: Principal or policy already exists while creating "host/carbon.li694-22@LI694-22".
	kadmin: ~~'''~~ktadd host/carbon.li694-22@LI694-22~~'''~~		kadmin: ktadd host/carbon.li694-22@LI694-22
	(lots of information)		(lots of information)
	kadmin: quit</pre>		kadmin: quit</pre>

Xlefay: /* Creating Users */

2014-03-24T03:24:22Z

Creating Users

← Older revision		Revision as of 03:24, 24 March 2014
Line 53:		Line 53:
	Creating users is the most common task, and doing so is very simple. Just add_principle, set a password, and you're done		Creating users is the most common task, and doing so is very simple. Just add_principle, set a password, and you're done

	<pre>kadmin: ~~'''~~add_principal martyb~~'''~~		'''add_principal martyb'''

			<pre>kadmin: add_principal martyb
	WARNING: no policy specified for martyb@LI694-22; defaulting to no policy		WARNING: no policy specified for martyb@LI694-22; defaulting to no policy
	Enter password for principal "martyb@LI694-22":		Enter password for principal "martyb@LI694-22":