[22764] in Kerberos
Re: User instances
daemon@ATHENA.MIT.EDU (Rachel Elizabeth Dillon)
Wed Oct 27 15:40:23 2004
Date: Wed, 27 Oct 2004 14:56:33 -0400
From: Rachel Elizabeth Dillon <red@mit.edu>
To: Fredrik Tolf <fredrik@dolda2000.com>
Message-ID: <20041027185633.GX300@yiff.mit.edu>
Mime-Version: 1.0
In-Reply-To: <1098899686.23619.12.camel@pc7.dolda2000.com>
cc: kerberos@mit.edu
Content-Type: multipart/mixed; boundary="===============88908356485391304=="
Errors-To: kerberos-bounces@mit.edu
--===============88908356485391304==
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="Sh7h4lnU5nPTsIof"
Content-Disposition: inline
--Sh7h4lnU5nPTsIof
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, Oct 27, 2004 at 07:54:45PM +0200, Fredrik Tolf wrote:
> Is there no way to just add one single general rule to cover all users,
> analogous to filename matching in Makefiles? That is, something like
> this:
>=20
> %/admin@REALM.COM x %/*@REALM.COM
>=20
> Where, as in make, `%' would have to match the same thing in both
> places?
>=20
> It's not that it would be a problem to add every user manually, but I
> guess it would be better if I didn't have yet another step to take when
> I want to add a user.
The manpage for kadmind does not suggest that any such rule exists. It
might be a convenient thing to add in, or it might exist in the source=20
but not be documented; I don't know. I expect it doesn't, but that's
just a guess. =20
=20
> > will give users full permissions on any principals with their username,
> > but I recommend not just using this line for a couple of reasons:
> > [snip]
> > * If you want to manage things like password expiry, users can circumv=
ent
> > you at the KDC level.
>=20
> Is there no way to force a certain policy onto principals?
You absolutely can! You can make username/cron whatever policy you want.
But if username/admin has administrative privileges on username/cron,
then username/admin can just take that policy away. :) I _think_ that you
can give users adMcil permissions rather than x and be safe from this,
but I haven't actually tried. (This gives them the ability to do everything
except modify principals, so that whatever rules you put in place will
stick.)
=20
> > I personally think this is a bad idea, but not knowing anything about
> > your situation, that judgment seems arbitrary. "What are you really
> > trying to do?" :)
>=20
> It's mainly that I want users to be able to create principals for
> automatic usage, like username/cron or username/gdm-autologin or the
> like (you know, create a principal with -randkey and storing it in a
> keytab for program that need to setuid without password). I'm going to
> be switching to NFSv4 in a while, and it would be a pity if people
> couldn't have cron jobs anymore just because they wouldn't have access
> to their own home directories...
> It's really just a home network, not a production site or anything, but
> we use Kerberos extensively for SSO and I really just want to solve all
> the problems I come across canonically, or I'd think bad of myself. :-)
> For example, my sisters like to have gdm log them in automatically (so
> that they don't have to type their passwords), and thus I need some
> extra principals to do that job. Likewise with cron.
So the solution I would suggest is sketchy in a different way :) I personal=
ly,
maybe because I often work with users who I do not trust not to eat their
own hands, would be very loath to give anyone any sort of access to the kdc
or kadmin interface that they do not specifically need. So probably I would
make each user a username/daemon principal, put it in their home directory
with permissions set to 400, and use that for cron, login, etc. This does m=
ean
that the same principal has a lot of power, but it only has as much power a=
s=20
that user does, which doesn't seem like too much of a risk. And in some ways
it is probably easier to keep track of.=20
That said, I _think_ you can do it your way and be OK, though I haven't
tested it.=20
> Thanks for replying!
Best of luck :)
-r.
--Sh7h4lnU5nPTsIof
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBf+9hrAG/UVUP/b0RAm6pAJ9EYPxmCmE7mLm06b65hoP9G4fSsQCgjLb1
woFhUDpJoCyi/eCzwDfG2EU=
=6KES
-----END PGP SIGNATURE-----
--Sh7h4lnU5nPTsIof--
--===============88908356485391304==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
--===============88908356485391304==--
