Big data security management -- the use of FreeIPA

1. Description

Hadoop's security default suite is Kerberos, and we can manually install the various components of Kerberos on each node. You can also use integrated security suites provided by operating system vendors, FreeIPA is one of them. HDP also supports the deployment of FreeIPA in their Ambari installation.
FreeIPA is an open source component provided by CentOS (I have only used this operating system, the name in RedHat does not seem to be this). But I think it is more like a collection of open source software. In Baidu Encyclopedia, it is defined as:

FreeIPA is an integrated security information management solution. FreeIPA includes Linux (Fedora), 389 Directory Server
MIT Kerberos, NTP, DNS, Dogtag (Certificate System) and other identity, authentication and policy functions.

2. Installation and deployment instructions

There are many documents for the installation and deployment of FreeIPA. Here I only record the problems I have encountered and think that they are more important:

2.1 CentOS version issue

  1. CentOS 6.6 is deprecated. Reason: https://bugs.centos.org/view.php?id=8757&nbn=2
  2. The installation of FreeIPA is best consistent with the version of CentOS. That is to say, assuming that the version of the operating system is CentOS 6.5, then it is best to install FreeIPA from CentOS 6.5. Because I have encountered such a problem: the operating system version is 6.5, but the installed FreeIPA is from the yum source on the Internet (like 6.7), and the result is wrong.

2.2 Enter a space

When installing IPAClient, be careful not to enter symbols such as spaces

[root@ipa112 ~]# ipa-client-install --domain=example.com --realm=EXAMPLE.COM --principal=admin@EXAMPLE.COM --password=hadoop123 --enable-dns-updates  --permit --no-ntp
Provide your IPA server name (ex: ipa.example.com): ipa110.example.com  --输入ipaserver,需要注意后面一定不要带空格,否则就会抛出异常

2.3 The node name must meet the requirements of FQDN

FreeIPA cluster must password FQDN.
Reason: freeipa has a domain concept (kerberos also has it), and kerberos requires all nodes to be in a domain. When we install freeipa, we will install kerberos together.
During the installation process, the installation script will automatically obtain the current machine name (which is the master node of freeipa), and resolve the corresponding domain name.
We can get it from the prompt information of its installation script: The domain name has been determined based on the host name
In addition, our machine name must not be called similar to hadoop.sec19. It is absolutely impossible to distinguish it by sec19 after the dot of. From the perspective of freeipa, its domain name is sec19,
which will cause all our machines to be not in the same domain.

2.4 DNS description

DNS is used for machine name resolution. If you install FreeIPA dual-machine (that is, master-slave Server), you need DNS
reason: we need to execute a command similar to the following:

  ipa-replica-prepare hadoop197.example.com --ip-address 192.168.116.197

At this time, it will go to the resolution on the DNS, and if it cannot find it, it will directly report an error. At this time, the slave node cannot be installed.
If we only install a single node of freeipa, we can not use DNS.

3 FreeIPA components

Write picture description here
The above figure is a component relationship diagram given by RedHat. From the figure, we can generally understand its organizational relationship. Where Directory Server is its core

3.1 Directory Server

FreeIPA's directory service uses the open source 389 DS. It is an open source software based on the LDAP protocol. It can be said to be the basis of the whole body system. Kerberos user data will be stored in the Directory Server database

3.1.1 Document Description

Directory Server is an LDAP service, and LDAP-based services include Windows AD. For DS, the files we may involve are as follows, and their locations are listed.

file or directory location
log file /var/log/dirsrv/slap-{instance}
configuration file /var/dirsrv/slap-{instance}
database file /var/lib/dirsrv/slapd-{instance}

Note 1: The instance here is set when we execute the installation and deployment. For example, in this article , its value is EXAMPLE.COM, then our log path is /var/log/dirsrv/slap-EXAMPLE.COMNote
2: DS data is stored in a database named Berkeley DB

3.1.2 Multi-Master Description

Generally speaking, we will deploy two IPAServers, that is, two Masters, and then artificially divide them into: the master node and the slave node. But that's an "incorrect" description. But because FreeIPA's scripts are distinguished, we describe them this way. In fact, for DS itself, it does not distinguish between "master-slave" Masters, it can have multiple Masters (the network-level configuration of more than two Masters has not been tested, and the record here is an official description of it)
Each master is both an information provider and a consumer. When a master updates the data, it will push corresponding changes to other masters. If there is a conflict, it will be handled by the conflict algorithm; if it still cannot be resolved, the conflict will be marked and the administrator will handle it.
For each modification, a change state number (Change state NumberCSN) will be set, which can uniquely identify this modification, and this number is composed of two parts: the time stamp and the identifier of the master that can define this modification, and The conflict resolution algorithm is very simple, that is, "the one who modifies later wins".

3.1.3 Configuration modification

In using FreeIPA, we may modify the corresponding configuration as needed. FreeIPA provides two modification methods: WebUI interface modification and LDAP format file. The following is an explanation of the two modifications I encountered

3.1.3.1 Password rule modification

User password policy is a very common configuration. Users can configure it through the web UI. Its configuration location is shown in the figure:
Write picture description here
If the user has not configured a password policy, then the default password policy will be used, that is, global_policy in the above figure. Click it to see the policy configuration information as shown in the figure below: The following table
Write picture description here
is Description of specific items:

name meaning
Max lifetime(days) The maximum time for user passwords, the default is 90 days
Min lifetime(hours) After the user modifies the user password, it must wait for a period of time before it can be modified again. This timetable is the shortest modification timetable, which defaults to 1 hour. The unit is also hours. It is to prevent the user from changing the original password immediately after changing the password. Otherwise, a message will pop up: Constraint violation: Too soon to change password
History size(number of password) Record previous password history
minimum length The minimum length of the password. The default is 8, that is, the password length is not less than 8 characters. If you do not need to verify the password length, you can set it to 0
Max failures Maximum number of failures. That is, the maximum number of wrong passwords allowed by the user when logging in or kinit

Note: If you enter the wrong password too many times, you need to unlock it. At this time, when you execute the kinit command, the following information will appear:

[root@hdp136 ~]# kinit lch
kinit: Clients credentials have been revoked while getting initial credentials

At this time, execute the command on the KDC node (that is, the IPAServer node):

[root@hdp134 ~]# kadmin.local    <-----执行kadmin.local
Authenticating as principal admin/admin@EXAMPLE.COM with password.
kadmin.local:  getprinc  lch  <---查看用户信息情况
Principal: lch@EXAMPLE.COM
Expiration date: [never]
Last password change: Tue Feb 27 11:11:02 CST 2018
Password expiration date: Mon May 28 11:11:02 CST 2018
Maximum ticket life: 1 day 00:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Tue Feb 27 11:11:02 CST 2018 (lch@EXAMPLE.COM)
Last successful authentication: Tue Feb 27 11:12:23 CST 2018
Last failed authentication: Tue Feb 27 14:11:07 CST 2018
Failed password attempts: 6      <--------------打印信息表明已经超过最大失败次数
Number of keys: 4
Key: vno 3, aes256-cts-hmac-sha1-96, Special
Key: vno 3, aes128-cts-hmac-sha1-96, Special
Key: vno 3, des3-cbc-sha1, Special
Key: vno 3, arcfour-hmac, Special
MKey: vno 1
Attributes: REQUIRES_PRE_AUTH
Policy: [none]
kadmin.local:   modprinc -unlock lch@EXAMPLE.COM    <---输入的命令进行解锁
Principal "[email protected]" modified.

3.1.3.2 LDIF modification

Ldif is an LDAP data interchange format. LDIF is an ASCII format, which is used to exchange and export data between server and client or between two servers. It is also used to modify the LDAP server database. The configuration information of FreeIPA is set through ldif and then imported into the database. The following is an example of modifying the buffer size of the data exchange between the master and slave nodes.
The user information created on the slave node of the ipa server cannot be synchronized to the master node, but in the log:

sasl_io_recv failed to decode packet for connection....

At this point, you need to modify the size of the buffer size.
1. Create a package.ldif file with the following contents:

[root@ipa110 /]# cat package.ldif 
dn: cn=config
changetype: modify
replace: nsslapd-sasl-max-buffer-size
nsslapd-sasl-max-buffer-size: 2097152
  1. Execute the command to import ldif
[root@ipa110 /]# ldapmodify -h localhost -D "cn=directory manager" -w hadoop123 -f package.ldif -ZZ

Among them, hadoop123 behind -w is the administrator password, which is the password entered when executing ipa-server-install. Execute on several nodes, then restart, and use buffer to take effect.

3.2 SSSD

3.2.1 Operating System Users

SSSD is not listed in RedHat's diagram, it does not belong to IPAServer, but to IPAClient. It is mainly used for Linux system user management.
We know that when we use the useradd command to create a user, it will be recorded in the /etc/passwd file of linux. However, the information of users created by freeipa is not stored in /etc/passwd, but in the database of DS. So how does it work?
Linux has a configuration file

[root@hdp136 ~]# cat /etc/nsswitch.conf
... 
passwd:     files sss
... 

The files in this configuration file refer to the local files of Linux, such as /etc/passwd, and sss refers to a kernel process in Linux:

[root@hdp136 ~]# service sssd status
sssd (pid  1799) is running...

When we use the user to log in to the linux system, the process is as follows:

Write picture description here

It should be noted that sssd itself has a cache, and it will not go to the ldap server to query user information from time to time, so we don't need to worry about the slow login caused by the network.

3.2.2 SSSD log configuration

If SSSD needs to modify the log level, it can be modified as follows:

[root@hdfs142 sssd]# vi /etc/sssd/sssd.conf 

[domain/example.com]

cache_credentials = True
debug_level = 9    ---修改这个值然后重启sssd

Then restart the corresponding sssd, that is, you can view the detailed instructions in /var/log/ssssd/ldap_child.log

4. Reference documents

  1. https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/index.html
  2. https://www.freeipa.org/page/Documentation

Guess you like

Origin blog.csdn.net/eyoulc123/article/details/79386263