[Freeipa-users] Creating arbitrary users?

[Simo Sorce]

On Tue, 2015-04-07 at 22:01 -0400, Coy Hile wrote:
> > On Apr 7, 2015, at 2:58 PM, Simo Sorce <simo at redhat.com> wrote:
> > 
> > On Tue, 2015-04-07 at 18:54 +0000, Coy Hile wrote:
> >> Quoting Simo Sorce <simo at redhat.com>:
> >> 
> >>>>> 
> >>>>> 
> >>>> I guess that makes sense. Is it possible to add a user that simply
> >>>> doesn't have the posix attributes  defined? In the particular case of
> >>>> */admin, I would expect that user to login to the ipa ui or to be
> >>>> kinit'd to prior to running ipa administrative commands, but I should
> >>>> hope that it should never login directly.
> >>>> 
> >>>> Does that question make more sense?
> >>> 
> >>> It does, but we do not have such a feature, sorry.
> >>> 
> >>> Simo.
> >>> 
> >> 
> >> Could one hypothetically remove the posix attributes (via some scripted
> >> process that validates that what it's doing is inline with organizational
> >> norms/goals) without breaking freeIPA, or are the posix attributes MUST in
> >> the IPA object classes?   I'm sorry for so many endless questions, but having
> >> finally got my personal setup/lab using something other than Active Directory,
> >> I'm looking to migrate to something that is easier to manage, so I'm trying to
> >> draw comparisons between what I had been used to in previous vanilla krb/ldap
> >> shops.
> > 
> > Removing attributes will probably not work well, but let me ask:
> > Do you require different passwords for these principals ?
> > Or do you merely want to have the alternative names but would be ok if
> > the credentials were identical ?
> > 
> > Because you could (manually for now) add aliases so that hile@
> > hile/admin@ hile/foo@ are the same thing, where hile@ is the canonical
> > name but you can use aliases too (just make sure not to request
> > canonicalization at kinit time.
> > 
> 
> My intent was that they have different passwords (and perhaps
> differing password policies.) For example, a /admin principal might
> enforce password expiry with a shorter lifespan than a normal
> principal, or might have a shorter maximum ticket lifetime before
> kinit -R is necessary.  It’s merely convenient that these other
> instances not necessarily be posix accounts to enforce there’s no
> possible way that, for example, someone logs in and is running a full
> GNOME session as an admin.  But I can live with them being posix
> accounts since it’s baked in.
> 
> We’ve all heard the horror stories of the Microsoft shops where some
> genius decided to login to his workstation with his juser_domainadmin
> account, or worse Administrator….
> 

You can use HBAC to prevent these users from logging in via
gdm/ssh/login etc...

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York