Re: Best practices for "pure" remote accounts

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



The accounts are stored in Radius or LDAP.

I've used nss_ldap.so and inserting "ldap" into the password/shadow sections of /etc/nsswitch.conf.  That mostly works, but if I don't want to require a local home directory, I've done the following:

sudo mkdir -m 1777 /home/guest
sudo echo "nss_override_attribute_value homeDirectory /home/guest" >> /etc/ldap.conf

to avoid requiring either creating home directories or using autofs+NFS to mount home directories.

Works well enough modulo some issues with the prompt.

What's the equivalent functionality for Radius?  Or is there none?  Will "sss" do it generically for Radius?

Just tried adding "sss" to /etc/nsswitch.conf but the Radius server NAK's the request if $HOME doesn't exist on the client which I don't get.  How does the server know whether the user has a home directory on the client or not?

Thanks


> On Oct 20, 2023, at 1:32 PM, James Yu Wang <yuwang@xxxxxxxxxx> wrote:
> 
> Where are the accounts stored? 
> 
> PAM allows you to stack modules. For example, you can use pam_krb5 to auth
> off AD and pam_radius to auth off radius. You stack them in the 'auth'
> section in pam.d config file. 
> 
> You use NSS to get users' uid, gid, homedir, etc information. Nslcd and sssd
> can do that. You put pam_ldap or pam_sss in the 'account' section in pam.d
> config file and append 'ldap' or 'sss' in the 'passwd' and 'shadow' lines in
> /etc/nsswitch.conf.
> 
> 
> -----Original Message-----
> From: Pam-list <pam-list-bounces@xxxxxxxxxx> On Behalf Of Philip Prindeville
> Sent: Friday, October 20, 2023 3:09 PM
> To: Pluggable Authentication Modules <pam-list@xxxxxxxxxx>
> Subject: Re: Best practices for "pure" remote accounts
> 
> Yes, this would be for multiple machines.
> 
> Also, my understanding is that sssd works with LDAP/AD but not with Radius?
> 
> I'd like to find something that works with both.
> 
> Looking for a deployment guide that explains how PAM, NSS, and SSSD all fit
> together.
> 
> 
> 
> 
>> On Oct 19, 2023, at 6:03 AM, James Yu Wang <yuwang@xxxxxxxxxx> wrote:
>> 
>> Hello,
>> 
>> Since you only care about username, uid, gid, and loginshell 
>> (management CLI), If you only have one appliance, then just use the 
>> /etc/passwd file with pam_unix. If you have multiple appliances, then 
>> considering centralized authentication and authorization like ldap with
> pam_sss.
>> 
>> James
>> 
>> -----Original Message-----
>> From: Pam-list <pam-list-bounces@xxxxxxxxxx> On Behalf Of Philip 
>> Prindeville
>> Sent: Wednesday, October 18, 2023 1:04 PM
>> To: pam-list@xxxxxxxxxx
>> Subject: Best practices for "pure" remote accounts
>> 
>> Hi,
>> 
>> I was wondering what the conventional wisdom is in the following
> scenario...
>> 
>> I'm working on a downstream distro that uses Debian/Ubuntu bases, and 
>> we allow users to log into an appliance (or "server", if you prefer, 
>> but not really).  For now we have to go ahead and create a placekeeper 
>> account with no password for each user for LDAP or Radius 
>> authentication to work, but I saw some articles on stackoverflow and
> elsewhere talking about "authconfig"
>> and "nslcd", etc.
>> 
>> Our requirements are such that having a "seed" user that everyone gets 
>> cloned as is fine, so they can inherit that uid, gid, and 
>> (nonexistent) home directory as they won't be dropping into a shell 
>> but into a management CLI instead.
>> 
>> We just need to be able to tell them apart by username.
>> 
>> And we can block access to scp/sftp if needed for that uid/gid so we 
>> don't have to worry about them creating files since they don't have a 
>> home directory of their own.
>> 
>> How is this typically solved in the most lightweight way possible?
>> 
>> Thanks,
>> 
>> -Philip

-- 
You received this message because you are subscribed to the Google Groups "pam-list@xxxxxxxxxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pam-list+unsubscribe@xxxxxxxxxx.




[Index of Archives]     [Fedora Users]     [Kernel]     [Red Hat Install]     [Linux for the blind]     [Gimp]

  Powered by Linux