Changes

Jump to navigation Jump to search
no edit summary
Line 13: Line 13:  
These lines are a translation of the method given by Daniel: https://wikit.firewall-services.com/doku.php/tuto/ipasserelle/authentification/ubuntu_sssd_on_sme. Many thanks to him for it.
 
These lines are a translation of the method given by Daniel: https://wikit.firewall-services.com/doku.php/tuto/ipasserelle/authentification/ubuntu_sssd_on_sme. Many thanks to him for it.
    +
==Backup==
 +
{{Warning box|This process may lock you out of the client machine. Make sure that on the client machine you have a local only user account with a name that is different to any users on the server e.g. 'localadminuser'
 +
It is worth taking a backup of the following files
 +
/etc/pam.d/common-account
 +
/etc/pam.d/common-auth
 +
/etc/pam.d/common-password
 +
/etc/pam.d/common-session
 +
/etc/pam.d/common-session-noninteractive
 +
}}
 +
 +
cp /etc/pam.d/common* /home/myhome/backup
 +
 +
==Assumptions==
 
In this how-to we assume that:
 
In this how-to we assume that:
 
  the host name of the SME is "sme-server" and the domain is "domain.tld".
 
  the host name of the SME is "sme-server" and the domain is "domain.tld".
    
==Configuration of the SME-server==
 
==Configuration of the SME-server==
There is quite no necessary configuration of the SME.  
+
There is little configuration required in SME server.  
*The only thing to do is to create a user (named "auth" in this how-to) via the server-manager and to give him a valid password ("something_very_secret" in the how-to).
+
*The only thing to do is to create a user (named "auth" in this how-to) via the server-manager and to give them a valid password ("something_very_secret" in the how-to).
 
It is not required to make "auth" member of any group.
 
It is not required to make "auth" member of any group.
    
*In addition, it is recommended to install and configure [[PHPki]] in order to make the managing of the self-created certificates easier.
 
*In addition, it is recommended to install and configure [[PHPki]] in order to make the managing of the self-created certificates easier.
   −
==Configuration of the client Ubuntu==
+
==Configuration of the Ubuntu client==
 
===Installation of the required packages===
 
===Installation of the required packages===
 
  sudo apt-get install sssd libnss-sss libpam-sss auth-client-config
 
  sudo apt-get install sssd libnss-sss libpam-sss auth-client-config
 
===Create a symbolic link===
 
===Create a symbolic link===
It seems to be a bugg in the version of sssd from Ubuntu, therefore following links must be created:
+
There seems to be a bug in the version of sssd from Ubuntu and therefore the following links must be created:
 
  ln -s /usr/lib /usr/modules
 
  ln -s /usr/lib /usr/modules
 
Without it, sssd can't manage membership to the groups in LDAP (source http://us.generation-nt.com/bug-599644-sssd-unable-resolve-ldap-group-memberships-help-200739341.html)
 
Without it, sssd can't manage membership to the groups in LDAP (source http://us.generation-nt.com/bug-599644-sssd-unable-resolve-ldap-group-memberships-help-200739341.html)
   −
===Manage the CA of the SME===
+
===Managing the CA on SME===
after having installed PHPki, go to https://www.domain.tld/phpki and download on the client machine the certificate of authority (ca-certificates.crt).
+
==PHPKi==
 +
 
 +
After having installed PHPki, go to https://www.domain.tld/phpki and download the certificate of authority (ca-certificates.crt) to the client machine.
    
Place a copy of it or of another CA into /etc/ssl/certs/ and give the 644 permissions:
 
Place a copy of it or of another CA into /etc/ssl/certs/ and give the 644 permissions:
  cp ~/download/ca-certificates.crt /etc/ssl/certs/
+
  cp ~/Downloads/ca-certificates.crt /etc/ssl/certs/
 
  chmod 644 /etc/ssl/certs/ca-certificates.crt
 
  chmod 644 /etc/ssl/certs/ca-certificates.crt
 +
 +
==Letsencrypt==
 +
 +
If you use Letsencypt for your certificates then your client machine should already have the ca-certificate for letsencrypt installed
 +
 +
You should be able to set the following in sssd.conf
 +
 +
ldap_tls_cacert = /etc/ssl/certs/ca-certificates.crt
    
===Configure SSSD===
 
===Configure SSSD===
The configuration of sssd is achieved in a classical way (as for Ubuntu or Fedora for exemple) and is made by the file /ets/sssd/sssd.conf.
+
The configuration of sssd is achieved in a standard way (as per Ubuntu or Fedora for example) and is made by the file /ets/sssd/sssd.conf.
   −
* At the beginning of this file, the used domain has to be set. In sssd, a domain can be taken as a source of content. it is possible to set several domains in order of priority.  
+
* At the beginning of this file, the used domain has to be set. In sssd, a domain can be taken as a source of content. It is possible to set several domains in order of priority.  
 
* And deeper in the file, we will add the configuration of the domain  
 
* And deeper in the file, we will add the configuration of the domain  
   −
If the file doesn't exist by default it has to be created and it needs to get the permissions 600 to allow the daemon to start:
+
If the file doesn't exist by default it has to be created and it needs to get the permissions 600 to allow the daemon to start.
 +
On Ubuntu clients using sudo you may need to get a root shell first:
    +
sudo -i
 +
 +
Now we can copy and paste this into the terminal:
 
  cat <<'_EOF' > /etc/sssd/sssd.conf
 
  cat <<'_EOF' > /etc/sssd/sssd.conf
 
  [sssd]
 
  [sssd]
Line 55: Line 82:  
   
 
   
 
  [pam]
 
  [pam]
+
 
 
  [domain/LDAP]
 
  [domain/LDAP]
 +
# Debug is now per domain
 +
# Debug level can be 0-10 for simple levels,
 +
# or for more control hex values Format is 0xXXXX
 +
# 1 = 0x0010 2 = 0x0020 3 = 0x040 4 = 0x080 5 = 0x0100 6 = 0x0200
 +
# see man sssd for more
 +
# https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/sssd-troubleshooting
 +
debug_level = 3
 
  id_provider = ldap
 
  id_provider = ldap
 
  auth_provider = ldap
 
  auth_provider = ldap
Line 86: Line 120:  
  #ldap_access_filter = (|(posixMemberOf=admins)(uid=backup))
 
  #ldap_access_filter = (|(posixMemberOf=admins)(uid=backup))
 
  _EOF
 
  _EOF
+
 
 +
Now we need to set the correct permissions on the file:
 
  chmod 600 /etc/sssd/sssd.conf
 
  chmod 600 /etc/sssd/sssd.conf
   −
{{Tip box|Make sure that the file /etc/ssl/certs/ca-certificates.crt contains the CA that has sign the certificate of the SME (if  PHPki is used, a version > 0,82-13 is required).}}
+
{{Tip box|Make sure that the file /etc/ssl/certs/ca-certificates.crt contains the CA that has signed the certificate of the SME (if  PHPki is used, a version > 0,82-13 is required).}}
    
===Configure the system to use SSSD as a source of authentication:===
 
===Configure the system to use SSSD as a source of authentication:===
Use the tool auth-client-config:
+
Setup to use the tool auth-client-config.  
vim /etc/auth-client-config/profile.d/sss
  −
and add following lines:
      +
{{Tip box|If you intend to automatically mount shares please see the Mount Shares section below and add the relevant sections to pam_auth and pam_session here first. You may also want the section in System Permissions }}
 +
 +
We can copy and paste in a terminal to add following lines:
 +
 +
cat <<'_EOF' > /etc/auth-client-config/profile.d/sss
 
  [sss]
 
  [sss]
 
  nss_passwd=    passwd:        compat sss
 
  nss_passwd=    passwd:        compat sss
Line 123: Line 161:  
                 session        [success=1 default=ignore]      pam_sss.so
 
                 session        [success=1 default=ignore]      pam_sss.so
 
                 session        required                        pam_unix.so
 
                 session        required                        pam_unix.so
 +
_EOF
    
And enable this:
 
And enable this:
 
  sudo auth-client-config -a -p sss
 
  sudo auth-client-config -a -p sss
 +
 +
Now you should be able to reboot and login as a LDAP member.
 +
 +
We should be able to restore the original pam config files with
 +
 +
sudo auth-client-config -a -p sss -r
 +
 +
 +
==Desktop Setup==
 +
 +
{{Warning box|msg=This seems to work on my Xubuntu Trusty 14.04 but YMMV!}}
 +
 +
===Sudoers===
 +
 +
Create a 'cliadmins' group on the server. This will be used to identify domain users to the desktop machine.
 +
 +
So that domain users have sudo rights we need to add this group to /etc/sudoers
 +
 +
NOTE - use visudo so you do not break this file ! :
 +
 +
sudo visudo
 +
 +
Add this:
 +
%cliadmins ALL=(ALL) ALL
 +
 +
 +
===System Permissions & PolicyKit===
 +
 +
I also found to enable shutdown/restart, network indicator etc I had to add this to /etc/auth-client-config/profile.d/sss
 +
 +
pam_session=
 +
                session        optional                        pam_systemd.so
 +
 +
Check if you run Policykit (most likely):
 +
 +
pgrep -lf polkit
 +
 +
To allow admin access on the desktop we need to edit the following file:
 +
/var/lib/polkit-1/localauthority/10-vendor.d/com.ubuntu.desktop.pkla
 +
 +
Add the following to sections as required:
 +
 +
Identity=unix-group:admin;unix-group:sudo;unix-group:cliadmins
 +
 +
Sections:
 +
 +
[Mounting, checking, etc. of internal drives]
 +
[Setting the clock]
 +
[Adding or changing system-wide NetworkManager connections]
 +
[Update already installed software]
 +
[usb-creator]
 +
[Printer administration]
 +
[Modify error reporting settings]
 +
 +
===LightDM Login Box===
 +
 +
If you want to have a simple login box with manual login only you can do the following:
 +
 +
create /etc/lightdm/lightdm.conf.d/50-unity-greeter.conf
 +
 +
Add the following:
 +
 +
[SeatDefaults]
 +
greeter-show-manual-login=true
 +
greeter-hide-users=true
 +
 +
===Mount Shares===
 +
 +
{{Note box|The following page is worth a read https://wiki.contribs.org/Smeserver-tw-logonscript#Linux_client_integration
 +
It is possible to create a simple local pam_mount.conf.xml file and then load a per user config from the server}}
 +
 +
If you can successfully login with a domain account you can now try and automatically mounts shares.
 +
 +
You will require at least cif-utils and libpam-mount
 +
 +
sudo apt-get install libpam-mount cifs-utils
 +
 +
In the above file /etc/auth-client-config/profile.d/sss
 +
 +
We need to add the following to the sections for:
 +
 +
pam_auth=
 +
                auth          optional                        pam_mount.so    enable_pam_password
 +
 +
pam_session=
 +
                session          optional                        pam_mount.so    enable_pam_password
 +
 +
 +
 +
We now need to setup global mounts for all users with /etc/security/pam_mount.conf.xml
 +
 +
Note: you can exclude local users from mounting directories with sgrp setting. You MAY need need nounix in mntoptions (needs testing)
 +
 +
Add the following:
 +
 +
cat <<'_EOF' >/etc/security/pam_mount.conf.xml
 +
<pam_mount>
 +
<debug        enable  = "0" />
 +
<mntoptions  allow  = "nosuid,nodev,loop,encryption,fsck,nonempty,allow_root,allow_other,noexec" />
 +
<mntoptions  require = "nosuid,nodev,noexec" />
 +
<logout      wait    = "5" hup    = "0"    term="yes" kill="0" />
 +
<mkmountpoint enable  = "1" remove = "true" />
 +
<!-- Personal Directory-->
 +
<volume fstype    = "cifs"
 +
        server    = "sme.server.com"
 +
        path      = "%(USER)"
 +
        mountpoint = "/home/e-smith/files/users/%(USER)/Partages/Personnel"
 +
        options    = "uid=%(USER),nosuid,nodev,noexec"
 +
        user      = "*"
 +
        sgrp      = "admins"/>
 +
  <!-- General Directory-->
 +
<volume fstype    = "cifs"
 +
        server    = "sme.server.com"
 +
        path      = "artwork"
 +
        mountpoint = "/home/e-smith/files/users/%(USER)/Mounts/artwork"
 +
        options    = "uid=%(USER),nosuid,nodev,noexec"
 +
        user      = "*"
 +
        sgrp      = "admins"/>
 +
</pam_mount>
 +
_EOF
 +
 +
You may need to add a 'sec' option like this:
 +
 +
options    = "uid=%(USER),nosuid,nodev,noexec,sec=ntlmssp,vers=1.0"
 +
 +
Now when you login as a domain user your shares should mount and you should have full sudo access.
 +
 +
==Miscellaneous Notes==
 +
 +
===Local password required for sudo===
 +
 +
One irritation that I have seen is that when you run a program requiring sudo e.g. Synaptic it may ask you for the password of a LOCAL user, not the domain user.
 +
 +
I believe adding your new group to the following file will then present you with a list of users who can authenticate:
 +
 +
/etc/polkit-1/localauthority.conf.d/51-ubuntu-admin.conf
 +
 +
[Configuration]
 +
AdminIdentities=unix-group:sudo;unix-group:admin;unix-group:cliadmins
 +
 +
It will present an 'Authenticate' box with a list of users - I have not yet found how to just accept the password for the current logged in user (as per normal case for standalone user). Most likely it requires a modification to lightdm similar to above.
 +
 +
===pam_winbind===
 +
 +
You may get the following error:
 +
 +
PAM unable to dlopen(pam_winbind.so): /lib/security/pam_winbind.so: cannot open shared object file: No such file or directory
 +
 +
This is due to a file location issue. You can resolve this error by doing the following:
 +
 +
cd /lib;ln -s /lib/x86_64-linux-gnu/security security
 +
 +
===pam_kwallet===
 +
 +
If you do not use kwallet and get annoyed by this message:
 +
 +
PAM unable to dlopen(pam_kwallet.so): /lib/security/pam_kwallet.so: cannot open shared object file: No such file or directory
 +
 +
edit /etc/pam.d/lightdm and lightdm-greeter and comment lines containing the following:
 +
 +
pam_kwallet.so
 +
 +
 +
Wish I knew all this a week ago !
    
[[Category:Howto]]
 
[[Category:Howto]]

Navigation menu