Shulou(Shulou.com)06/01 Report--

How to achieve single sign-on for Kerberos+LDAP+NFSv4, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and easy way.

Kerberos+LDAP+NFSv4 implements single sign-on

VI. Installation of nfs client

Nfs client, also known as SSSD client, requires sssd and nfs-common to be installed

1. Install sssd

Libsasl2-modules-gssapi-mit is automatically installed (non-dependent)

Libsasl2-modules-gssapi-mit and libsasl2-modules-gssapi-heimdal conflict. It is also possible to install libsasl2-modules-gssapi-heimdal.

Root@debian:~# apt-get install sssd sssd-krb5 sssd-ldap libsasl2-modules-gssapi-heimdal

The installed sssd.conf is a blank file, and the nsswitch.conf has not changed.

Root@debian:~# ls-l / etc/sssd/sssd.conf-rw- 1 root root 1938 Jun 10 11:18 / etc/sssd/sssd.conf

Only the owner can read (the SSSD document requires that sssd.conf can only be read and written by the root root user, otherwise sssd cannot be started)

Modify configuration files sssd.conf, nsswitch.conf

1) View sssd.conf

Root@debian:~# cat / etc/sssd/sssd.conf

[sssd]

Config_file_version = 2

Services = nss, pam

Domains = intern

[nss]

[pam]

[domain/intern]

#-unix user information is provided by LDAP

Id_provider = ldap

#-^-

#-vMurt-user authentication and password modification are provided by Kerberos

Auth_provider = krb5

Chpass_provider = krb5

#-^-

Ldap_uri = ldap://192.168.1.101

Ldap_search_base = ou=hdkrb5,dc=ctp,dc=net

Ldap_tls_reqcert = allow

Krb5_server = 192.168.1.101

Krb5_realm = CTP.NET

#-- vMurt-some environments cannot always be authenticated without setting them. Password authentication should take a long time, and the timeout period should be a little larger.

Krb5_auth_timeout = 60

#-^-

Root@debian:~#

2) View nsswitch.conf

Root@debian:~# cat / etc/nsswitch.conf

Passwd: files sss

Group: files sss

Shadow: files sss

Gshadow: files

Hosts: files mdns4_minimal [NOTFOUND=return] dns

Networks: files

Protocols: db files

Services: db files sss

Ethers: db files

Rpc: db files

Netgroup: nis sss

Sudoers: files sss

Root@debian:~# changed the original compat to files sss.

3) automatically set / etc/pam.d/ when installing sssd

Linlin@debian:~$ cat / etc/pam.d/common-session-noninteractive

Session [default=1] pam_permit.so

Session requisite pam_deny.so

Session required pam_permit.so

Session required pam_unix.so

Session optional pam_umask.so umask=002

Linlin@debian:~$linlin@debian:~$ cat / etc/pam.d/common-session

Session [default=1] pam_permit.so

Session requisite pam_deny.so

Session required pam_permit.so

Session required pam_unix.so

Session optional pam_sss.so

Session optional pam_systemd.so

Session optional pam_umask.so umask=002

Linlin@debian:~$linlin@debian:~$ cat / etc/pam.d/common-password

Password requisite pam_pwquality.so retry=3

Password [success=2 default=ignore] pam_unix.so obscure use_authtok try_first_pass sha512

Password sufficient pam_sss.so use_authtok

Password requisite pam_deny.so

Password required pam_permit.so

Password optional pam_gnome_keyring.so

Linlin@debian:~$linlin@debian:~$ cat / etc/pam.d/common-auth

Auth [success=2 default=ignore] pam_unix.so nullok_secure

Auth [success=1 default=ignore] pam_sss.so use_first_pass

Auth requisite pam_deny.so

Auth required pam_permit.so

Auth optional pam_group.so

Linlin@debian:~$linlin@debian:~$ cat / etc/pam.d/common-account

Account [success=1 new_authtok_reqd=done default=ignore] pam_unix.so

Account requisite pam_deny.so

Account required pam_permit.so

Account sufficient pam_localuser.so

Account [default=bad success=ok user_unknown=ignore] pam_sss.so

Linlin@debian:~$

4) restart sssd

Root@debian:~# / etc/init.d/sssd stoproot@debian:~# / etc/init.d/sssd start

5) Test

Linlin@debian:~$ kpasswd krblinlin

Krblinlin@CTP.NET's Password:

New password for krblinlin@CTP.NET:

Verify password-New password for krblinlin@CTP.NET:

Success: Password changed

Linlin@debian:~$linlin@debian:~$ su krblinlinPassword:krblinlin@debian:/home/linlin$krblinlin@debian:/home/linlin$ passwd

Current Password:

New password:

BAD PASSWORD: The password is shorter than 8 characters

New password:

Retype new password:

Passwd: password updated successfully takes a long time

Krblinlin@debian:/home/linlin$

Login was successful, password modification commands kpasswd and passwd were successful. Note that the password is a Kerberos password, not a LDAP password

However, there is a problem in some environments. When the kdc server is restarted, the SSSD client cannot log in, and the daemon heimdal-kdc needs to be restarted on the kdc server manually, but the reason cannot be found. On the other hand, the environment is normal.

two。 Install nfs-common

Root@debian:~# apt-get install nfs-common

Modify / etc/default/nfs-common file

Set

NEED_GSSD=

Change to

NEED_GSSD= "yes"

Root@debian:~# / etc/init.d/nfs-common stoproot@debian:~# / etc/init.d/nfs-common start

Root@debian:~# ps-e | grep gss

1027? 00:00:00 rpc.gssd

1) Mount the network share

Manual mounting

Root@debian:~# mount-t nfs4 srvnf.ctp.net:/home/linlin/share / mnt-o sec=krb5

Or

Add to / etc/fstab, mount the network share as soon as you boot.

Root@debian:~# cat / etc/fstab

UUID=c992cbf5-3eca-4434-baf9-b5a3180acdbb / ext4 errors=remount-ro 0 1

# swap was on / dev/sda5 during installation

UUID=854aa36b-6ce5-436d-91fa-50aa10e8338c none swap sw 0 0

/ dev/sr0 / media/cdrom0 udf,iso9660 user,noauto 0 0

# add a network share

Srvnf.ctp.net:/home/linlin/share / mnt nfs4 rw,sec=krb5

Root@debian:~#

2) View mount information

Linlin@debian:~$ mount | grep nfs

Srvnf.ctp.net:/home/linlin/share on / mnt type nfs4 (rw,relatime,vers=4.0,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5,clientaddr=192.168.1.102,local_lock=none,addr=192.168.1.103)

3) Test and write network sharing

Root@debian:~# ls-ld / mntdrwxr-xr-x 2 krblinlin 4001 4096 Sep 18 09:13 / mntroot@debian:~#

You can see that the ldap user information has been obtained and displayed. Krblinlin is the ldap user.

Under ordinary local users

Linlin@debian:~$ su krblinlin

Password:

Or log in directly from the console

Debian login: krblinlin

Password:

Krblinlin@debian:/home/linlin$ cd / mntkrblinlin@debian:/mnt$ touch a.txtkrblinlinghouse debianVera MNT $lsa.txtkrblinlin@debian:/mnt$

Write successfully

Root@debian:~# ps-e | grep idmapd 533? 00:00:00 rpc.idmapd

So far, with LDAP as the storage of user information and Kerberos as authentication, the SSSD client has successfully accessed the read and write NFSv4 server network share

seven。 Postscript

The purpose of this paper is to create an active directory similar to FreeIPA and AD, but a perfect Kerberos system needs the cooperation of DNS and DHCP, so this paper is only an experiment.

There are many ways to realize single sign-on. LDAP also provides simple user authentication. If you do not need to apply NFSv4 or NFSv4 to use weak system authentication, and do not need to build Kerberos, only LDAP can satisfy single sign-on; while samba4 can easily create an active directory under linux.

1.

The Kerberos system, originally developed by MIT, the MIT Kerberos Project (http://web.mit.edu/kerberos/), is currently very active.

Another Kerberos system is the Heimdal Kerberos project (http://www.h6l.org/) in this article.

Why this article chooses Heimdal instead of MIT, as mentioned earlier, one is to use LDAP as the Kerberos backend, and the other is to avoid storing plaintext ldap database administrator passwords.

1) MIT supports LDAP as the backend through plug-ins, and the documentation also states that it supports EXTERNAL, but I can't figure out how to configure how to support EXTERNAL, and I don't have a clue when looking at the source code.

St = ldap_sasl_interactive_bind_s (server- > ldap_handle, NULL,ctx- > sasl_mech, NULL, NULL,LDAP_SASL_QUIET, interact, ctx)

Pass "EXTERNAL" to ctx- > sasl_mech through the configuration file

After looking up the information, it seems that ldap_sasl_interactive_bind_s should first ldap_get_option about LDAP_OPT_X_SASL_AUTHZID before using EXTERNAL. Although there is ldap_get_option in the source code of MIT, there are several LDAP_OPT_xxxx written in it, which has nothing to do with authentication and has nothing to do with SASL.

2) Heimdal has built-in support for LDAP as the backend, and default support for EXTERNAL. It is easy to view the source code.

Rc = ldap_sasl_bind_s (HDB2LDAP (db), NULL, "EXTERNAL", & bv,NULL, NULL, NULL)

3) openldap's synchronous password plug-in only supports Heimdal

2.openldap synchronization password

When logging in with Kerberos and LDAP, it is troublesome to maintain and remember two sets of passwords. There are three ways to use only one password

Method 1:

Use the {SASL} method, which needs to be configured as follows

Root@debian:~# cat / etc/sasl2/slapd.confpwcheck_method: saslauthdroot@debian:~#

Fill in the fixed value {SASL} for the userPassword attribute

This method is a way to search the Internet, I have not tried.

Method 2 and method 3: install the synchronous password plug-in slapd-smbk5pwd for openldap

Method 2:

Fill in the fixed value {K5KEY} for the userPassword attribute

Both method 2 and method 1 should be careful not to change the value of the userPassword attribute, and the password can only be changed in Kerberos mode

Method 3:

The password can only be modified in LDAP mode, and only in the way similar to ldappasswd command. At the same time, userPassword, krb5Key.

Ldappasswd is a tool to set the password of an LDAP user. Ldappasswd uses the LDAPv3 Password Modify (RFC 3062) extended operation.

Note that ldappasswd is an extension operation of LDAP. For details, please refer to RFC 3062.

My understanding of ldappasswd is to send unhashed plaintext passwords to the LDAP server, which is hashed into ciphertext and stored in the ldap database by the LDAP server itself.

While the ordinary ldap changes the password to hash the plaintext password into ciphertext on the client side, the LDAP server no longer changes and stores it to the ldap database, that is to say, the password attribute of the original LDAP is no different from other attributes, and the ordinary ldap modifies the password in the same way as modifying other attribute values.

Method 3 can synchronize three sets of passwords: Kerberos, LDAP and samba.

This article adopts mode 2 or mode 3

1) installation

Root@debian:~# apt-get install slapd-smbk5pwd

Slapd-smbk5pwd: Keeps Samba and Kerberos passwords in sync within slapd

2) load module

Root@debian:~# cat smbk5pwd.ldifdn: cn=module {0}, cn=configchangetype: modifyadd: olcModuleLoadolcModuleLoad: smbk5pwdroot@debian:~#root@debian:~# ldapadd-Y EXTERNAL-H ldapi:///-f smbk5pwd.ldif

3) heimdal-kdc has been installed before, and heimdal mode has been added to LDAP. As the purpose of this article is to synchronize Heimdal and not samba, there is no need to add samba mode.

4) change / var/lib/heimdal-kdc/m-key to be owned by openldap users

M-key original permission is owned by root, only root read and write. Openldap is started as an openldap user.

If you do not change the m-key permission first, but perform step 5 first), the ldapadd error will occur due to no permission.

Root@debian:~# chown openldap / var/lib/heimdal-kdc/m-key

5) enable synchronization

Root@debian:~# cat krb5.ldifdn: olcOverlay=smbk5pwd,olcDatabase= {1} mdb,cn=configchangetype: addobjectClass: olcOverlayConfigobjectClass: olcSmbK5PwdConfigolcOverlay: smbk5pwdolcSmbK5PwdEnable: krb5root@debian:~#root@debian:~# ldapadd-Y EXTERNAL-H ldapi:///-f krb5.ldif

6) restart openldap

Usually, the online configuration takes effect immediately, but due to the / var/lib/heimdal-kdc/m-key file permission problem, it is better to restart openldap.

7) Test

Log in as an ordinary local user

Linlin@debian:~$ ldappasswd-h 192.168.1.101-D "krb5PrincipalName=krblinlin@CTP.NET,ou=hdkrb5,dc=ctp,dc=net"-W-SNew password:Re-enter new password:Enter LDAP Password: old password (LDAP user password, not Kerberos user password) linlin@debian:~$

In this way, the password of the LDAP user is changed as well as the password of the Kerberos user, and it is normal to log in with the password of the Kerberos user.

Note that the permissions of the / var/lib/heimdal-kdc/m-key file should be correct (otherwise, although the ldappasswd prompt is successful, the value of the actual krb5Key attribute is broken and cannot be logged in with the Kerberos user password)

3. Because the LDAP installation process automatically sets other properties that can be read anonymously except userPassword, and the krb5Key attribute should contain Kerberos password information, do you need to set non-Kerberos users to prohibit reading krb5Key?

I am not talented. I have not seen any relevant information that is clearly forbidden. Is it impossible to crack the password without / var/lib/heimdal-kdc/m-key even if krb5Key is obtained illegally?

4. Set up SSSD login for non-local users to automatically create user directories

The above experimental krblinlin logs in to the client, which does not have a user directory for krblinlin.

You can use pam_mkhomedir.so to automatically create user directories, and pam_mkhomedir.so is in the libpam-modules package

1) installation

Root@debian:~# apt-get install libpam-modules

2) add a line of pam_mkhomedir.so to / etc/pam.d/common-session, which is roughly as follows

...

Session required pam_unix.so

#-- vMurt-add a new line to automatically create a user directory

Session required pam_mkhomedir.so umask=0077

#-^-

Session [success=ok default=ignore] pam_ldap.so minimum_uid=1000

...

3) Log in

Debian login: krblinlin

Password:

Creating directory'/ home/krblinlin'. Created a user directory after logging in normally for the first time

Krblinlin@debian:~$krblinlin@debian:~$ pwd/home/krblinlinkrblinlin@debian:~$

5. ACL of the file system (access control list)

Although NFSv4 is NFSv4 acl, this lab is still posix acl. Guess that NFSv4 acl may need local file system support. It seems that only zfs local file system supports NFSv4 acl.

6. Domain

LDAP domain and Kerberos domain can be different

That is, the realm of Kerberos is CTP.NET

The basic DN of LDAP can be dc=oled,dc=com

7. Other

Debian 9 installs openldap using mdb as the backend of LDAP, while LDAP can choose other backends such as hdb. Select a different backend, and its configuration directory, file name and configuration database entry content are based on the backend name.

If this lab is mdb

Root@debian:~# apt-get install treeroot@debian:~# tree / etc/ldap/slapd.d/etc/ldap/slapd.d |-- cn=config | |-- cn=module {0} .ldif | |-- cn=schema | |-- cn= {0} core.ldif |-- cn= {1} cosine.ldif |-- cn= {2} nis.ldif | |-- cn= {3} inetorgperson.ldif | | |-- cn=schema.ldif | |-- olcBackend= {0} mdb.ldif | |-- olcDatabase= {- 1} frontend.ldif | |-- olcDatabase= {0} config.ldif | |-- olcDatabase= {1} mdb.ldif |-- cn=config.ldifroot@debian:~# is just installed after openldap has been installed. |

If you want to recreate the ldap database

Root@debian:~# dpkg-reconfigure slapd

If hdb is selected as the backend in the configuration process, the relevant content is hdb

View the ldap database

Root@debian:~# slapcat

View the configuration database

Root@debian:~# slapcat-b cn=config

eight。 Correction

The environment of the experiment was debian 9 testing version.

Chapter 3, Section 1, Section 2) set the ACL access control list, and the line 'will'

OlcAccess: {2} to * by self write by dn= "cn=admin,dc=ctp,dc=net" write by * read

I don't remember whether it was set by the openldap installation package script itself, or I made a mistake. The line was changed from 'original' to 'copy to * by self write'.

This is a serious vulnerability and error.'to * by self write' allows ldap users to modify any attributes of their entries

For example, ldap users can set the uidNumber of their unix to 0, that is, root, which is dangerous, that is, ordinary users can entitle themselves (although the ldap client is configured by default to map the uidNumber value of ldap to 0 as a non-root user) or impersonate another user.

Therefore, the principle that ldap users are only allowed to modify themselves and password properties, other properties can only be set by the administrator.

Therefore, the original'is changed to 'the line.

OlcAccess: {2} to * by self write by dn= "cn=admin,dc=ctp,dc=net" write by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * read

Actually, it needs to be changed to

OlcAccess: {2} to * by dn= "cn=admin,dc=ctp,dc=net" write by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * read

This article has been revised.

Original complete olcAccess configuration without 'change' after installation of openldap for debian 10 testing

OlcSuffix: dc=ctp,dc=netolcAccess: {0} to attrs=userPassword by self write by anonymous auth by * noneolcAccess: {1} to attrs=shadowLastChange by self write by * readolcAccess: {2} to * by * readolcLastMod: TRUEolcRootDN: cn=admin,dc=ctp,dc=net 's answer to the question on how to implement single sign-on in Kerberos+LDAP+NFSv4 is shared here. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel for more related knowledge.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.