[Freeipa-users] user account without password

[Nordgren, Bryce L -FS]

Hi Alex, 

Just because I gave up doesn't mean there isn't a way. Does your partitioning of local/domain users allow a domain user to run a service on a machine? I was trying to run an iPython notebook server as my regular user/domain account via systemd. Much of the data that the service needed access to resided on a multi-Terabyte NFS share, hence the desire to make it work with my domain account. IIRC, systemd was the thing choking on the domain user. 

Do you just manually create a local user with the same attributes as the domain user? (and in the case of the above use NFS with sec=host)? 

Thanks,
Bryce

> -----Original Message-----
> From: Alexander Frolushkin [mailto:Alexander.Frolushkin at Megafon.ru]
> Sent: Sunday, April 12, 2015 9:27 PM
> To: Nordgren, Bryce L -FS; 'Martin Kosek'; freeipa-users at redhat.com
> Subject: RE: [Freeipa-users] user account without password
> 
> -----Original Message-----
> From: Nordgren, Bryce L -FS [mailto:bnordgren at fs.fed.us]
> Sent: Friday, April 10, 2015 9:27 PM
> To: Alexander Frolushkin (SIB); 'Martin Kosek'; freeipa-users at redhat.com
> Subject: RE: [Freeipa-users] user account without password
> 
> >> Also, if such account will also exist locally (my case), it will not
> >> be controlled by HBAC rules - it can be a some kind of security trap...
> 
> >Pretty sure accounts should be either local or domain-wide, but not both.
> Could lead to strange and unforeseen side effects. Last I checked, only local
> accounts can run services. It may be advantageous to allow local accounts
> (which can run services) to have a representation in the domain, but the local
> >accounts need to be scoped to the local machine (e.g., "apache" on server 1
> is different than "apache" on server 2). At least that way, they could belong
> to the same groups domain accounts belong to. SSO certainly shouldn't work.
> Any access to shared storage should distinguish between same-named
> >accounts on different machines.
> 
> >Alternatively, allowing domain accounts to run certain services also
> >has some merit. (assuming the user has permissions to do so.)
> 
> >Just thinking into email.
> >Bryce
> 
> I have a long and positive experience using both local and IPA users with the
> same attributes, but without HBAC and without sudo way to obtain shell of
> such users.
> Default settings in nsswitch.conf and pam provides straight and clear systems
> behavior, for about three years.
> But I agree there can be case when such construction may lead to
> misbehavior and so on. We will try to avoid them.
> SSO not really the aim for us, we just need to made a environment where
> users must remember only one password to access all resources on
> unix/linux servers.
> 
> Not trying to argue, just sharing some thoughts :) Alexander
> 
> ________________________________
> 
> Информация в этом сообщении предназначена исключительно для
> конкретных лиц, которым она адресована. В сообщении может
> содержаться конфиденциальная информация, которая не может быть
> раскрыта или использована кем-либо, кроме адресатов. Если вы не
> адресат этого сообщения, то использование, переадресация,
> копирование или распространение содержания сообщения или его
> части незаконно и запрещено. Если Вы получили это сообщение
> ошибочно, пожалуйста, незамедлительно сообщите отправителю об
> этом и удалите со всем содержимым само сообщение и любые
> возможные его копии и приложения.
> 
> The information contained in this communication is intended solely for the
> use of the individual or entity to whom it is addressed and others authorized
> to receive it. It may contain confidential or legally privileged information. The
> contents may not be disclosed or used by anyone other than the addressee.
> If you are not the intended recipient(s), any use, disclosure, copying,
> distribution or any action taken or omitted to be taken in reliance on it is
> prohibited and may be unlawful. If you have received this communication in
> error please notify us immediately by responding to this email and then
> delete the e-mail and all attachments and any copies thereof.
> 
> (c)20mf50