Arvutiteaduse instituut
  1. Kursused
  2. 2017/18 kevad
  3. Süsteemihaldus (LTAT.06.003)
EN
Logi sisse

Süsteemihaldus 2017/18 kevad

  • Home
  • Video Lectures
  • Practicals
  • Exam
  • References

Installing LDAP client

The Lightweight Directory Access Protocol (LDAP; /ˈɛldæp/) is an open, vendor-neutral, industry standard application protocol for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network.[1] Directory services play an important role in developing intranet and Internet applications by allowing the sharing of information about users, systems, networks, services, and applications throughout the network.[2] As examples, directory services may provide any organized set of records, often with a hierarchical structure, such as a corporate email directory. Similarly, a telephone directory is a list of subscribers with an address and a phone number. https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol

LDAP Client side

  1. Install Command line tools from package ldap-utils
  2. Download our ldap_ca_cert.pem from http://teacher.est/ldap/ldap_ca_cert.pem and save into /etc/ssl/certs under name ldapCA.pem. Make sure its readable for all (everybody).
  3. Modify /etc/ldap/ldap.conf and set: 
 BASE dc=sa18,dc=est
 URI  ldap://ldap.est/
 TLS_CACERT /etc/ssl/certs/ldapCA.pem
  • Test LDAP client,fetch all distinguished names (DN):
    • Use plain channel, no authentication:
      • ldapsearch -LLL -x dn
        • What are the options -LLL and -x responsible for? Refer to: man ldapsearch
    • Force TLS channel, no authentication:
      • ldapsearch -ZZ -LLL -x dn
        • What are the options -ZZ responsible for?
    • Force SSL channel, no authentication:
      • ldapsearch -H ldaps://ldap.est -LLL -x dn

... all previous queries should print the list of distinguished names (DN) defined in our directory, the first one is our directory tree root (dc=sa18,dc=est): 

dn: dc=sa18,dc=est
dn: ou=groups,dc=sa18,dc=est
dn: ou=people,dc=sa18,dc=est
dn: cn=students,ou=groups,dc=sa18,dc=est
dn: cn=teachers,ou=groups,dc=sa18,dc=est
...

The directory tree has 2 organizational units (OU): groups and people. You can modify ldap query to fetch only specific information by providing attribute filters (using attribute=value), additionally you can only query for a specific attributes by appending attribute names. Examples:

  1. Fetching all organizational units, printing all attributes 
 $ ldapsearch -LLL -x ou=*
  1. Fetching all organizational units, printing only (ou) attribute 
 $ ldapsearch -LLL -x ou=* ou
  1. Alternating search BASE (-b), fetching all distinguished names (dn) in groups unit (ou=groups,dc=sa18,dc=est) 
 $ ldapsearch -LLL -x -b 'ou=groups,dc=sa18,dc=est' dn

Figure out the ldap command to query only the distinguished names inside people organization unit.

  • Fetch only dn
  • How many records are there ?
  • What are the attributes of the records ?
  • Fetch only the displayName attribute
  • Can you see your name in the list ?
  • Fetch the information regarding your LDAP account, print all attributes

So far we did access the directory using no authentication, therefore LDAP restricted our queries to read-only. Also the secured account attributes like password hashes were hidden. Next let's try to authenticate and perform LDAP queries. In order to authenticate, we need to provide LDAP client the attribute to use to bind to when authenticating (-D option'), additionally we should force LDAP client to ask for password input (-W option). Otherwise password has to be provided from STDIN or through -w argument in plain text or through -y argument (password file). Examples:

  1. Tester figuring out his distinguished name in LDAP directory using attribute filter 
 $ ldapsearch -LLL -x givenName=Tester dn
  1. Tester is asking all information regarding his LDAP account (non-authenticated): 
 $ ldapsearch -LLL -x uid=tester
  1. The same query using authentication 
 $ ldapsearch -LLL -ZZ -WD 'uid=tester,ou=people,dc=sa18,dc=est' uid=tester

Please notice that in previous example tester asked LDAP to for TLS channel (-ZZ) when authenticating into LDAP. We advise all the authenticated access to LDAP to be done over secure channels like TLS.

  • Using TLS channel, authenticate using your LDAP distinguished name and fetch all the attributes of your LDAP account.
    • default Password is your Number of a study book aka Matrikli number ( all in UPPERCASE!)
    • Notice that in case of successful authentication, you should able to see the password hash of your account
      • attribute userPassword

In case you can authenticate and see your account data, you can actually change it, as the LDAP provides the read-write access to authenticated clients. Be aware you can only modify the attributes of your bound DN (-D option), since these are the bounds of your authorization. Examples: 

 # Tester changing the password
 ldappasswd -ZZ -WASD 'uid=tester,ou=people,dc=sa18,dc=est'

Here (-ZZ) enforces TLS channel, (-D) specifies the DN to bind to for authentication, (-W) forces password prompt for authentication, (-A) double-checks the old password, (-S) double-checks the new password.

Change the default password of your LDAP account. Refer to the example above. Please be aware the ldappasswd utility will:

  • first ask you old password twice
  • second ask you new password twice
  • submit the changes to LDAP
    • NB! will ask for an old password once more!

Verify if you can use your new password:

  • ldapsearch -LLL -ZZ -WD <your DN> uid=<your uid>

Optional: refer to ldapmodify utility and LDAP diff file format (*.ldif) try to modify the mail'' attribute of your LDAP account (use the email you did setup during the course, example user@<youdomain>.est)

Configuring Apache to authenticate against the LDAP

There routine is quiet similar to the one of Apache .httpsasswd file and Unix PAM back-ends of the HTTP authentication. Naturally we should declare a <Location ...> or <Directory ...> to limit the access to. This time we are not going to create an additional virtual host or specific document-root for LDAP auth. Instead we are going to use the LDAP status module (more info here as our <Location ...> target.

  • In your apache virtual host test.<yourdomain>.est SSL site definitiaon add the following Location directive 
<Location "/ldap-status">
    SetHandler ldap-status

    AuthType Basic
    AuthName "LDAP Protected"
    AuthBasicProvider ldap
    AuthLDAPURL ldap://ldap.est/ou=people,dc=sa18,dc=est?uid?one TLS
    Require valid-user

</Location>

As you can see here we enforce TLS channel therefore we also want apache to use our LDAP CA certificate to verify the LDAP server.

  • Make sure you did download LDAP CA in PEM format:
    • http://teacher.est/ldap/ldap_ca_cert.pem
    • Stored it in /etc/ssl/certs under name ldapCA.pem and made it readable for all
  • Download the LDAP CA in DER format:
    • http://teacher.est/ldap/ldap_ca_cert.der
    • Stored it in /etc/ssl/certs under name ldapCA.der and make it readable for all
  • In /etc/apache2/conf-available/
    • Create a configuration file ldap-certs.conf
    • Add the following lines: 
LDAPTrustedGlobalCert CA_BASE64 /etc/ssl/certs/ldapCA.pem
LDAPTrustedGlobalCert CA_DER /etc/ssl/certs/ldapCA.der
  • Enable apache2 modules ldap and authnz_ldap
  • Enable newly create configuration ldap-certs.conf (using a2enconf)
  • Check the syntax and restart apache

Test LDAP by accessing from your local browser:

https://test.<yourdomain>.est/ldap-status

  • should ask for authentication against LDAP server where username is ut_login_name and the default Password (if you did not change it previously) is your "Number of a study book" aka "Matrikli number." PS! all uppercase letters)

Installing Nextcloud

ownCloud is a suite of client-server software for creating file hosting services and using them. ownCloud is functionally very similar to the widely used Dropbox, with the primary functional difference being that ownCloud is free and open-source, and thereby allowing anyone to install and operate it without charge on a private server.[2] It also supports extensions that allow it to work like Google Drive, with online document editing, calendar and contact synchronization, and more. Its openness avoids enforced quotas on storage space or the number of connected clients, instead having hard limits (like on storage space or number of users) defined only by the physical capabilities of the server. https://en.wikipedia.org/wiki/OwnCloud

Nextcloud is a suite of client-server software for creating and using file hosting services. It is functionally similar to Dropbox, although Nextcloud is free and open-source, allowing anyone to install and operate it on a private server. In contrast to proprietary services like Dropbox, the open architecture allows adding additional functionality to the server in form of applications and enables the user to have full control of their data. The original ownCloud developer Frank Karlitschek forked ownCloud and created Nextcloud, which continues to be actively developed by Karlitschek and other members of the original ownCloud team. https://en.wikipedia.org/wiki/Nextcloud

OwnCloud and Nextcloud (being forks) are very similar in a way they behave and install. Though in our experience Nextcloud is more advanced and many owncloud servers (including https://owncloud.ut.ee/ is actually running Nextcloud nowadays).

Snappy is a software deployment and package management system originally designed and built by Canonical for the Ubuntu phone operating system. The packages, called 'snaps' and the tool for using them 'snapd', work across a range of Linux distributions and allow therefore distro-agnostic upstream software deployment. The system is designed to work for phone, cloud, internet of things and desktop computing. "Snap" application packages of software are self-contained and work across a range of Linux distributions. This is unlike traditional Linux package management approaches, like APT or YUM, which require specifically adapted packages for each Linux distribution. This adds delay between application development and its deployment for end-users. https://en.wikipedia.org/wiki/Snappy_(package_manager)

Install Nextcloud using snap package manager

  • # apt install snapd
  • # snap install nextcloud

By default snap will try to use port 80 that is already used for Apache service so we need to reconfigure default port our nextcloud will listen on

  • # snap set nextcloud ports.http=8080
  • # snap set nextcloud ports.https=8443

After the installation create a Local Port Forwarding Tunnel over SSH in your host machine

  • In Putty at the menu on the left click on SSH and under that on Tunnels. Under the Add new forwarded port add 8080 as source port and 127.0.0.1:8080 as destination. Click Add. (We did that for phpinfo so if you need more help take a look at Apache lab)
  • open your web browser with http://localhost:8080. Now the configuration screen opens and configure freely chosen username and password as in the picture...

After that you should be able to login and start configuring your personal nextcloud server.

  • As a security feature nextCloud only allows logins from trusted domains so edit configuration file /var/snap/nextcloud/current/nextcloud/config/config.php and add correct values to 'trusted_domains' parameter. You can also achieve this by using nextcloud.occ command
    • # nextcloud.occ config:list
    • # nextcloud.occ config:system:get trusted_domains
    • # nextcloud.occ config:system:set trusted_domains 3 --value=www.<yourdomain>.est:8080

PS! If nextcloud.occ command is missing from path log out and log in as root user again.

  • Enable https connections to your nextcloud
    • Copy sertificates:
      • # cp /etc/ssl/certs/server.crt /var/snap/nextcloud/current/certs/live/server.pem
      • # cp /etc/ssl/private/server.key /var/snap/nextcloud/current/certs/live/server.key
      • # cp /etc/ssl/certs/cacert.crt /var/snap/nextcloud/current/certs/live/cacert.pem
    • Now lets enable HTTPS for nextcloud 
      •  # nextcloud.enable-https custom /var/snap/nextcloud/current/certs/live/server.pem /var/snap/nextcloud/current/certs/live/server.key /var/snap/nextcloud/current/certs/live/cacert.pem
  • In order to restart snap services (so new config would be applied) you can restart the whole snapd service or only its sub-processes (i.e snap.nextcloud.apache, snapd.refresh) or enable / disable nextcloud snap.
    • # service snapd restart
    • # service snapd.apache restart
    • # snap disable nextcloud
    • # snap enable nextcloud
  • After enabling HTTPS you might be automatically redirected to HTTPS and its port 8443 that is not forwarded, so you might need to make another port forwarding for port 8443 to gain access.
  • Now lets add a 100 MB Limit to all users for that go to small gear sign upper-right corner -> Users and look for a Settings in the lover-left corner Default quota -> other -> 100MB.
    • Also check following boxes Show storage location, Show user backend, Show last login

Enable the LDAP user and group backend app on the Apps page under nextcloud settings -> Apps -> Disabled Apps. Then go to your Admin page to configure it. You can read more info and explanations about parameters from here https://doc.owncloud.org/server/9.1/admin_manual/configuration_user/user_auth_ldap.html

In LDAP Server tab

  • provide ldap server address ldap.est
  • click detect port, should find the 389 automatically
  • skip User DN and Password settings
  • provide Base DN
    • dc=sa18,dc=est
  • click Test Base DN
    • should state Configuration OK
  • Proceed to Users tab
  • set object filter to posixAccount
  • in group filters allow the following groups
    • teachers, students
  • Proceed to Groups tab
  • In object filters allow the following objects
    • groupOfNames
  • In group filters allow the following groups
    • teachers, students
  • Click the settings button (rightmost-upper corner)
    • Select Users
      • After fetching for a while it should show all the users form LDAP

Making Nextcloud public

Currently our Nextcloud is nested on ports 8080 and 8443 of our VM and in fact is no accessible without SSH tunneling. Let's make it a proper virtual host and serve it through our apache!

First of all we will need a FQDN for our nextcloud, lets call it: nextcloud.<yourdomain>.est

Modify the DNS server settings:

  • Add one more CNAME for nextcloud.<yourdomain>.est

Make sure your new CNAME is added properly

  • Check in VM: $ nslookup nextcloud.<yourdomain>.est
  • Check in personal host: $ ping nextcloud.<yourdomain>.est

Next let's define a new Apache virtual host for our nextcloud

  • Add a site configuration for nextcloud
    • Create a corresponding site conf. file in /etc/apache2/sites-available
  • Create a new document root folder for nextcloud virtual host
    • Create a directory nextcloud in /var/www/vhosts
    • Delegate the directory to user www-data group www-data
    • Create an index.html file inside the document rood dir:
      • # echo 'This is the Nextcloud proxy page' >> /var/www/vhosts/nextcloud/index.html
      • Delegate the index.html to user www-data group www-data
  • Edit the nextcloud site configuration file:
    • Set ServerName to nextcloud.<yourdomain>.est
    • Set DocumentRoot to /var/www/vhosts/nextcloud
    • Set CustomLog to ${APACHE_LOG_DIR}/nextcloud.log combined
    • NB! if http to https redirect is not done globally, add it here
  • Save file

Add an SSL configuration file for nextcloud.<yourdomain>.est site

  • Create another SSL site configuration file in /etc/apache2/sites-available
  • Edit the nextcloud SSL site configuration file:
    • Set ServerName to nextcloud.<yourdomain>.est
    • Set DocumentRoot to /var/www/vhosts/nextcloud
    • Set CustomLog to ${APACHE_LOG_DIR}/nextcloud-ssl.log combined
  • Save file
  • Enable newly create sites
  • Check the configuration syntax
  • Restart apache

In VM command line: $ wget --no-check-certificate -O - http://nextcloud.<yourdomain>.est

In personal host: Open link in your browser: http://nextcloud.<yourdomain>.est

The automatic redirect to https should occur The following statement should be returned: 

'This is the Nextcloud proxy page'

Finally let's enable mod proxy and expose our nextcloud to public using ReverseProxy settings

In apache /etc/apache2/sites-available, in nextcloud SSL site configuration file:

  • Add the following lines: 
# Enable proxifying https
SSLProxyEngine On
# Trust all certs (the one we used in nextcloud is our-made anyway)
SSLProxyCheckPeerCN Off
SSLProxyCheckPeerExpire Off
  • Add the following location directive: 
<Location "/">
    SSLRequireSSL

    # Route everything https://nextcloud.yourdomain.est/ ->
    #   https://127.0.0.1:8443/
    ProxyPass https://127.0.0.1:8443/
    # ... and backwards
    ProxyPassReverse https://127.0.0.1:8443/
    # Do not mask the client IP, let the next cloud see the client's
    # IP instead of proxy's IP
    ProxyPreserveHost On

</Location>
  • Save the file
  • Enable modules: proxy proxy_http proxy_http2
  • Check the configuration syntax
  • Restart apache

In personal host: Open link in your browser: http://nextcloud.<yourdomain>.est The automatic redirect to https should occur You should see the nextcloud title page, with the warning 

Add 'nextcloud.mydomain.est' as trusted domain'

Well this is OK as the nextcloud is configured in localhost:8080 and localhost:8443 of the VM so it expects himself to be referred correspondingly. Nextcloud knows nothing about our new Proxy schema, so it is surprised to be referred as nextcloud.yourdomain.est. Now we just have to calm it down by making it aware of its new referrals. This however can be only done through trusted channel. For nextcloud the only valid is still through localhost:8080 and localhost:8443 therefore we need our SSH tunnel to be up before we click the Add ' button.

Make sure the SSH tunnel is established and clic the Add ... button in the browser

Finally nextcloud should trust the Proxy and therefore the you should be able to see the same page when accessing the nextcloud with your browser:

  • through SSH tunnel
  • and directly using http://nextcloud.<yourdomain>.est

In the end you can close the SSH tunnel!

By default nextcloud stored data in snap folder /var/snap/nextcloud/common/nextcloud/data, but thats not most convenient as we would like to keep main disk small and store all user/additional files on second data partition. In order to do that we must reconfigure nextcloud to allow external media locations and in our case /dev/vdb1 disk.more info here https://github.com/nextcloud/nextcloud-snap/issues/150

Then lets allow external media locations

  • # snap connect nextcloud:removable-media

Now lets modify nextcloud main configuration file

  • # nano /var/snap/nextcloud/current/nextcloud/config/config.php
    • change datadirectory parameter to /media/vdb1/nextcloud,

Nextcloud only allows use of /media folder as location for external storage so lets mount /mnt/vdb1 folder as /media/vdb1 folder

  • In /etc/fstab add a line 
  /mnt/vdb1       /media/vdb1     none    bind    0 0

Mount the filesystem

  • # mkdir /media/vdb1
  • # mount /media/vdb1

Lets turn off nextcloud.

  • # snap disable nextcloud

Now lets copy all of Nextcloud data to new folder

  • # cp -rTp /var/snap/nextcloud/common/nextcloud/data /media/vdb1/nextcloud

Finally lets enable nextcloud again

  • # snap enable nextcloud

Now under @@users tab in owncloud you should see that storage location has been changed.

  • Arvutiteaduse instituut
  • Loodus- ja täppisteaduste valdkond
  • Tartu Ülikool
Tehniliste probleemide või küsimuste korral kirjuta:

Kursuse sisu ja korralduslike küsimustega pöörduge kursuse korraldajate poole.
Õppematerjalide varalised autoriõigused kuuluvad Tartu Ülikoolile. Õppematerjalide kasutamine on lubatud autoriõiguse seaduses ettenähtud teose vaba kasutamise eesmärkidel ja tingimustel. Õppematerjalide kasutamisel on kasutaja kohustatud viitama õppematerjalide autorile.
Õppematerjalide kasutamine muudel eesmärkidel on lubatud ainult Tartu Ülikooli eelneval kirjalikul nõusolekul.
Courses’i keskkonna kasutustingimused