Made by :
Ben Hnia Intidhar
Abdelkefi Farah
Ben Hajla Nour
to install the server , we run this command :
sudo apt install slapd ldap-utils
to change the Directory Information Tree (DIT) suffix , we run the following command :
sudo dpkg-reconfigure slapd`
we used dc=example,dc=com
We create the following file called add-users.ldif :
Now to implement the change, we run the below command :
ldapadd -x -D cn=admin,dc=example,dc=com -W -f add-users.ldif
Users have been added to the server .
Now we do the same thing to add groups to the server : We create the file called add-groups.ldif file
we run this command to implement the change :
ldapadd -x -D cn=admin,dc=example,dc=com -W -f add-groups.ldif
To modify a user , we create a file called modify-user.ldif:
To implement the changes , we run the following command :
ldapmodify -x -D cn=admin,dc=example,dc=com -W -f modify-user.ldif
We create a directory for certificates authority
mkdir ~/projet/ldap/auth
we generate CA certificate
openssl genrsa -out ca.priv 2048
openssl rsa -in ca.priv -pubout -out ca.pub
openssl req -x509 -new -days 3650 -key ca.priv -out ca.cert
Now we generate certificates for users and sign them
mkdir ~/projet/ldap/clients && cd ~/projet/ldap/clients
openssl genrsa -out user1.priv 2048
openssl rsa -in user1.priv -pubout -out user1.pub
openssl req -new -key user1.priv -out user1.csr
openssl genrsa -out user2.priv 2048
openssl rsa -in user2.priv -pubout -out user2.pub
openssl req -new -key user2.priv -out user2.csr
cd ~/projet/ldap/auth
openssl x509 -req -in ~/projet/ldap/clients/user1.csr -CA ca.cert -CAkey ca.priv -CAcreateserial -out ~/projet/ldap/clients/user1.cert -days 3650
openssl x509 -req -in ~/projet/ldap/clients/user2.csr -CA ca.cert -CAkey ca.priv -CAcreateserial -out ~/projet/ldap/clients/user2.cert -days 3650
To add ther certificates to user , we install LDAP Acount Manager LAM /
sudo apt -y install ldap-account-manager
We access the LAM management interface in your browser http://localhost/lam and we add the generated certificates
1-1- First we create the key by running the following command
openssl genrsa -aes128 -out example.com.key 4096
1-2- Now to remove the passphrase from the generated private key we run
openssl rsa -in example.com.key -out example.com.key
1-3- Now we generate the request :
openssl req -new -days 3650 -key example.com.key -out example.com.csr
1-4- finally, we sign the certificate by running this command :
sudo openssl x509 -in example.com.csr -out example.com.crt -req -signkey example.com.key -days 3650
2-1- Now let's copy the certificates and key to /etc/ldap/sasl2 directory :
We run
sudo cp example.com.{key,crt} /etc/ldap/sasl2/
sudo cp /etc/ssl/certs/ca-certificates.crt /etc/ldap/sasl2`
2-2- Now we change Ownership of the certificate to openldap User . We run this command
sudo chown -R openldap:openldap /etc/ldap/sasl2/
to see the changes we run ll /etc/ldap/sasl2/
2-3- We create LDAP configuration file called SSL-LDAP.ldif :
2-4- To configure LDAP Server to use SSL Certificates , We run :
sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f SSL-LDAP.ldif
2-5- we edit /etc/default/slapd.We run
sudo nano /etc/default/slapd
and we add ldaps:/// to SLAPD_SERVICES
2-6- we edit /etc/ldap/ldap.conf. We run
sudo nano /etc/ldap/ldap.conf
and we comment line TLS_CACERT etc/ssl/certs/ca-cerificates.crt and we add
TLS_CACERT /etc/ldap/sasl2/ca-certificates.crt
TLS_REQCERT allow
Finally ,We restart LDAP Server :
sudo systemctl restart slapd
We Verify by executing ldapsearch command :
ldapsearch -x -H ldaps://192.168.56.103 -b "dc=example,dc=com"
It worked
Step 1: Install the necessary LDAP client packages on the client machine and configure the server's IP address:
sudo apt-get install ldap-utils libpam-ldap libnss-ldap
Edit the /etc/nsswitch.conf file to include LDAP in the data sources for name resolution:
sudo nano /etc/nsswitch.conf
Make sure the following lines include "ldap":
passwd: compat ldap
group: compat ldap
shadow: compat ldap
Edit the /etc/pam.d/common-session file to include LDAP session:
sudo nano /etc/pam.d/common-session
Add the following line:
session required pam_mkhomedir.so skel=/etc/skel/ umask=077
sudo systemctl restart nscd
sudo systemctl restart nslcd
sudo login
# Enter the UID
# Enter the password
Run the below commands to install the necessary packages i
sudo apt-get install openssh-server libpam-ldap
then we edit sshd_config in /etc/ssh/ by running
sudo nano /etc/ssh/sshd_config
and we edit sshd in /etc/pam/ by running
sudo nano /etc/pam.d/sshd
and we edit access.conf in /etc/security/ by running
sudo nano /etc/security/access.conf
restart ssh to enable the new configuration by running
sudo systemctl restart ssh
then we try to test SSH access for an authorized user and an unauthorized user by running these commands in the clients machines
ssh username@your_server_ip
First we install apache2 by executing this command
sudo apt-get -y install apache2
after creating certificates for the server, we add these two lines
SSLCertificateFile /etc/ssl/private/server.crt SSLCertificateKeyFile /etc/ssl/private/server.key
to /etc/apache2/sites-available/default-ssl.conf file
then we run this commands
a2ensite default-ssl
a2enmod ssl
To activate the new configuration , we run
sudo systemctl restart apache2
Now we can access to the page from a client computer with a Web browser via HTTPS.
this screen is shown because Certificates is self-signed but it's not a problem,we click on Accept the Risk and Continue
we run this command :
a2enmod ldap authnz_ldap
we create a new file called auth-ldap.conf in etc/apache2/sites-availables/ :
We only let the users in group2 (user2) access the page
we run this command
a2ensite auth-ldap
and restart apache2 to enable the new configuration by running
sudo systemctl restart apache2
Now, we create a new directory called auth-ldap in /var/www/html/ and we create index.html in it
when we try to access the page with user1 (not in group2 ) :
We have to re-enter the username and password because he's not authorized to access the page.
Now, we try to access it with user2 (in group2):
we access it with user2
Make sure to install OpenVPN on your Ubuntu server:
sudo apt update
sudo apt install openvpn
Edit the /etc/pam.d/openvpn file:
auth requisite pam_unix.so
auth required pam_ldap.so
account requisite pam_unix.so
account required pam_ldap.so
Restart the OpenVPN and LDAP services to apply the changes:
sudo systemctl restart openvpn
sudo systemctl restart slapd
we write the server Configuration : server.ovpn
We run
sudo openvpn --config server.ovpn
we write the client Configuration : user1.ovpn
We run
sudo openvpn --config user1.ovpn
The Domain Name System (DNS) is the phonebook of the Internet. Humans access information online through domain names, like nytimes.com or espn.com. Web browsers interact through Internet Protocol (IP) addresses. DNS translates domain names to IP addresses so browsers can load Internet resources.
Each device connected to the Internet has a unique IP address which other machines use to find the device. DNS servers eliminate the need for humans to memorize IP addresses such as 192.168.1.1 (in IPv4), or more complex newer alphanumeric IP addresses such as 2400:cb00:2048:1::c629:d7a2 (in IPv6).
The reference DNS server, BIND (Berkeley Internet Name Domain), is from the Internet Software Consortium.
sudo apt-get install bind9
The main configuration of BIND9 is done in the following files:
/etc/bind/named.conf
/etc/bind/named.conf.options
/etc/bind/named.conf.local
We will configure a forwarder, which is a DNS server that will handle requests that your server cannot resolve, essentially all requests except those for the zone that we will host for our local machines.
To do this, we will modify named.conf.options with the command:
sudo nano /etc/bind/named.conf.options
We uncomment the forwarders block and specify, for example, the IP address of the DNS server provided by the DHCP server of your router. We have set the IP address of a Google DNS like 8.8.8.8 and 8.8.4.4
To host our own zone as the master server, we will modify the named.conf.local file using the command:
sudo nano /etc/bind/named.conf.local
Then, we need to create the file /etc/bind/local.lan to go along with it. To do this, we will copy db.local, which serves as a reference. You type:
sudo cp /etc/bind/db.local /etc/bind/local.lan
Edit the file with
nano /etc/bind/local.lan
we modify the zone. Here we define the Start Of Authority (SOA). For this, we declare ns (for Name server). We also declare a second name, root, here
After defining the SOA, still ns, we also declare one or more A-type records. An A-type record allows mapping a DNS name to an IP address.
we need to create the file /etc/bind/inv.lan
sudo cp /etc/bind/db.127 /etc/bind/inv.lan
Edit the file with
nano /etc/bind/inv.lan
we have also to edit /etc/resolv.conf
sudo nano /etc/resolv.conf
we have first to add zones in named.conf.local
then add records in local.lan
and then w create the files apache.lan, ldap.lan and openvpn.lan using
sudo cp /etc/bind/db.127 /etc/bind/apache.lan
sudo cp /etc/bind/db.127 /etc/bind/ldap.lan
sudo cp /etc/bind/db.127 /etc/bind/openvpn.lan
edit them with:
nano /etc/bind/apache.lan
nano /etc/bind/ldap.lan
nano /etc/bind/openvpn.lan
Restart BIND9 with
sudo service bind9 restart
From there, on another machine, you should be able to test the resolution of ns.local.lan. On a Windows machine, you can type in a command prompt:
nslookup
We instruct nslookup to use your Linux server as the DNS server
server 192.168.56.102
Now, we try to resolve ns.local.lan
ns.local.lan
apache.local.lan
ldap.local.lan
openvpn.local.lan
now in reverse:
Kerberos is a network authentication protocol designed to provide secure authentication for client-server applications. The primary goal of Kerberos is to enable secure communication over a non-secure network, such as the Internet.
1.The user initiates a service request and forwards a ticket-granting ticket (TGT) request to the Kerberos Authentication Server (AS).
2.The AS validates the user's identity and responds by providing an encrypted TGT.
3.Upon decrypting the TGT, the user submits it to the Ticket-Granting Server (TGS) to obtain a service ticket.
4.The TGS authenticates the TGT and issues a service ticket in return.
5.With the received service ticket in hand, the user transmits it to the Service Server.
6.At this point, the client gains access to the requested service, leveraging the provided service ticket.
We begin by verifying and synchronizing the clocks of the two machines :
Clock synchronization is crucial in the context of Kerberos due to how the protocol manages ticket validity periods. Kerberos relies on timestamps to ensure the security and authenticity of exchanges between parties.
We start by executing this command
hostnamectl --static set-hostname kdc.example.com
We do the same for the client machine
Now we need to get the IP Adresses of all the two machines:
KDC: 192.168.56.102 Client: 192.168.56.101
The next step is to add the IP adresses of the two machines in /etc/hosts files. We execute this command :
sudo gedit /etc/hosts
now we can test the communication with:
ping client
ping kdc
We first start exectuing these commands in order to install krb5-kdc, krb5-admin-server and krb5-config libraries needed for this step:
sudo apt-get update
sudo apt-get install krb5-kdc krb5-admin-server krb5-config
krb5-kdc : provides the central authentication server for Kerberos.
krb5-admin-server : provides the administration server for the KDC.
krb5-config : provides configuration files and scripts for setting up and managing a Kerberos realm.
We now execute this command :
sudo krb5_newrealm
This command create a new Kerberos realm on a server. It will create new Kerberos database and administration server key, generate a new Kerberos configuration file for the new realm and set up the initial set of administrative principals and policies for the new realm.
When installing the packages, some prompts will appear in order to configure the KDC server
Realm : EXAMPLE.COM (must be in uppercase)
Kerberos server : kdc.example.com
Administrative server : kdc.example.com (in our case it's the same as the kdc server)
We find that these files were created :
stash:
The stash file is often associated with securing the Kerberos database. It's typically a stash file used to securely store the master key of the Kerberos Key Distribution Center (KDC).
In other words, during the Kerberos server configuration, the master key of the KDC is often stored in a stash file. This file needs to be protected as it contains sensitive information.
kadm5.acl:
The kadm5.acl file specifies access rules for administering the Kerberos server. It determines which individuals or principals have the right to perform administrative operations on the Kerberos database. Administrative operations include creating principals, modifying password policies, etc.
Here is the list of principals before adding new ones :
We start with the user principal:
sudo kadmin.local
kadmin.local: add_principal user1
We can verify that the principal is created
kadmin.local: list_principals
we can verify the details of the principal created :
Now we create the admin principal:
kadmin.local: add_principal root/admin
Next, we need to grant all access rights to the Kerberos database to admin principal root/admin in the configuration file /etc/krb5kdc/kadm5.acl
sudo nano /etc/krb5kdc/kadm5.acl
To establish authentication between a Kerberos client and server without requiring user interaction, a keytab file is used. This file contains the principal and its associated key, allowing services to authenticate without user input.
Use the ktutil utility to create a keytab file.
Inside ktutil, assign a key to root/admin.
we also add the host :
The authentication principle in Kerberos with SSH involves using the Kerberos protocol to establish the identity of users and secure communications over a network. SSH, which stands for Secure Shell, is a secure network protocol that allows secure access to remote machines over an unsecured network.
SSH is a secure communication protocol used for encrypted access to remote machines. It is commonly used for remote server administration, secure file transfers, and executing commands on remote machines. Authentication in SSH can be achieved using various methods, such as password entry, the use of public/private keys, and also through integration with Kerberos.
When a user wants to connect to a remote machine via SSH, they can use their Kerberos ticket to authenticate without entering an additional password. The Kerberos ticket serves as proof of the user's identity, eliminating the need to share passwords directly with the remote server.
We start by modifying two files: sshd_config and ssh_config, uncommenting these two lines: GSSAPIAuthentication yes and GSSAPICleanupCredentials yes.
"GSSAPIAuthentication yes" enables authentication via the Generic Security Services Application Program Interface (GSSAPI), which is a standard authentication framework used in various systems.
"GSSAPICleanupCredentials yes" specifies that GSSAPI credentials should be cleaned up after the connection. This allows for the release of resources associated with GSSAPI authentication once the connection is terminated.
By uncommenting these lines in the SSH configuration files (sshd_config for the SSH server and ssh_config for the SSH client), we activate GSSAPI authentication. This modification may be necessary in environments where Kerberos ticket-based authentication is used, for example, to enhance SSH access security. It provides an additional authentication method based on the system's security mechanisms, thereby expanding authentication options for users and system administrators.
Firstly, verify the list of principals (user and admin) and check the keytab associated with root/admin.
Create the host and add the keytab for the host.
Then, add a user. Initially, when attempting to access kds.example.com, the user need to enter the password
Assigning a ticket to this user involves using the kinit command to generate a ticket for 'user1.
After generating the ticket, you can use the klist command to confirm its presence.
Then, when you attempt to SSH into 'kdc.example.com', the user should be able to access the machine without providing a password.
Perform the same steps by installing Kerberos (krb5-user) and configuring it.
Verify the krb5.conf file as shown in the screenshot below:
Then, install OpenSSH server and modify the configuration files, similar to what was done on the KDC machine
Add a user and attempt to access the machine. Initially, there is no ticket.
Access 'kdc.example.com' (initially with the password).
Generate a ticket and confirm its generation, as shown in the screenshot:
Access the machine without entering the password, as depicted in the screenshots:
On the KDC machine, view the log of the client machine accessing it :
Perform a simple test:
On the KDC machine, echo the hostname into a file.
Test on the client machine to verify the consistency of results.
KDC Machine:
Client Machine:
