此内容没有您所选择的语言版本。
13.5. Migrating from NIS to IdM
There is no direct migration path from NIS to Identity Management. This is a manual process with three major steps: setting up netgroup entries in IdM, exporting the existing data from NIS, and importing that data into IdM. There are several options for how to set up the IdM environment and how to export data; the best option depends on the type of data and the overall network environment that you have.
13.5.1. Preparing Netgroup Entries in IdM
The first step is to identify what kinds of identities are being managed by NIS. Frequently, a NIS server is used for either user entries or host entries, but not for both, which can simplify the data migration process.
For user entries
Determine what applications are using the user information in the NIS server. While some clients (like sudo) require NIS netgroups, many clients can use Unix groups instead. If no netgroups are required, then simply create corresponding user accounts in IdM and delete the netgroups entirely. Otherwise, create the user entries in IdM and then create an IdM-managed netgroup and add those users as members. This is described in Section 13.3, “Creating Netgroups”.
For host entries
Whenever a host group is created in IdM, a corresponding shadow NIS group is automatically created. These netgroups can then be managed using the ipa-host-net-manage command.
For a direct conversion
It may be necessary to have an exact conversion, with every NIS user and host having an exact corresponding entry in IdM. In that case, each entry can be created using the original NIS names:
- Create an entry for every user referenced in a netgroup.
- Create an entry for every host referenced in a netgroup.
- Create a netgroup with the same name as the original netgroup.
- Add the users and hosts as direct members of the netgroup. Alternatively, add the users and hosts into IdM groups or other netgroups, and then add those groups as members to the netgroup.
13.5.2. Enabling the NIS Listener in Identity Management
The IdM Directory Server can function as a limited NIS server. The
slapi-nis plug-in sets up a special NIS listener that receives incoming NIS requests and manages the NIS maps within the Directory Server. Identity Management uses three NIS maps:
- passwd
- group
- netgroup
Using IdM as an intermediate NIS server offers a reasonable way to handle NIS requests while migrating NIS clients and data.
The
slapi-nis plug-in is not enabled by default. To enable NIS for Identity Management:
- Obtain new Kerberos credentials as an IdM admin user.
[root@ipaserver ~]# kinit admin
- Enable the NIS listener and compatibility plug-ins:
[root@ipaserver ~]# ipa-nis-manage enable [root@ipaserver ~]# ipa-compat-manage enable
- Restart the DNS and Directory Server service:
[root@server ~]# service rpcbind restart [root@server ~]# service dirsrv restart
13.5.3. Exporting and Importing the Existing NIS Data
NIS can contain information for users, groups, DNS and hosts, netgroups, and automount maps. Any of these entry types can be migrated over to the IdM server.
Migration is performed by exporting the data using
ypcat and then looping through that output and creating the IdM entries with the corresponding ipa *-add commands. While this could be done manually, it is easiest to script it. These examples use a shell script.
13.5.3.1. Importing User Entries
The
/etc/passwd file contains all of the NIS user information. These entries can be used to create IdM user accounts with UID, GID, gecos, shell, home directory, and name attributes that mirror the NIS entries.
For example, this is
nis-user.sh:
#!/bin/sh
# 1 is the nis domain, 2 is the nis master server
ypcat -d $1 -h $2 passwd > /dev/shm/nis-map.passwd 2>&1
IFS=$'\n'
for line in $(cat /dev/shm/nis-map.passwd); do
IFS=' '
username=$(echo $line|cut -f1 -d:)
# Not collecting encrypted password because we need cleartext password to create kerberos key
uid=$(echo $line|cut -f3 -d:)
gid=$(echo $line|cut -f4 -d:)
gecos=$(echo $line|cut -f5 -d:)
homedir=$(echo $line|cut -f6 -d:)
shell=$(echo $line|cut -f7 -d:)
# Now create this entry
echo passw0rd1|ipa user-add $username --first=NIS --last=USER --password --gidnumber=$gid --uid=$uid --gecos=$gecos --homedir=$homedir --shell=$shell
ipa user-show $username
done
This can be run for a given NIS domain:
[root@nis-server ~]# kinit admin [root@nis-server ~]# ./nis-user.sh nisdomain nis-master.example.com
Note
This script does not migrate user passwords. Rather, it creates a temporary password which users are then prompted to change when they next log in.
13.5.3.2. Importing Group Entries
The
/etc/group file contains all of the NIS group information. These entries can be used to create IdM user group accounts with the GID, gecos, shell, home directory, and name attributes that mirror the NIS entries.
For example, this is
nis-group.sh:
#!/bin/sh
# 1 is the nis domain, 2 is the nis master server
ypcat -d $1 -h $2 group > /dev/shm/nis-map.group 2>&1
IFS=$'\n'
for line in $(cat /dev/shm/nis-map.group); do
IFS=' '
groupname=$(echo $line|cut -f1 -d:)
# Not collecting encrypted password because we need cleartext password to create kerberos key
gid=$(echo $line|cut -f3 -d:)
members=$(echo $line|cut -f4 -d:)
# Now create this entry
ipa group-add $groupname --desc=NIS_GROUP_$groupname --gid=$gid
if [ -n "$members" ]; then
ipa group-add-member $groupname --users=$members
fi
ipa group-show $groupname
done
This can be run for a given NIS domain:
[root@nis-server ~]# kinit admin [root@nis-server ~]# ./nis-group.sh nisdomain nis-master.example.com
13.5.3.3. Importing Host Entries
The
/etc/hosts file contains all of the NIS host information. These entries can be used to create IdM host accounts that mirror the NIS entries.
For example, this is
nis-hosts.sh:
#!/bin/sh
# 1 is the nis domain, 2 is the nis master server
ypcat -d $1 -h $2 hosts | egrep -v "localhost|127.0.0.1" > /dev/shm/nis-map.hosts 2>&1
IFS=$'\n'
for line in $(cat /dev/shm/nis-map.hosts); do
IFS=' '
ipaddress=$(echo $line|awk '{print $1}')
hostname=$(echo $line|awk '{print $2}')
master=$(ipa env xmlrpc_uri |tr -d '[:space:]'|cut -f3 -d:|cut -f3 -d/)
domain=$(ipa env domain|tr -d '[:space:]'|cut -f2 -d:)
if [ $(echo $hostname|grep "\." |wc -l) -eq 0 ]; then
hostname=$(echo $hostname.$domain)
fi
zone=$(echo $hostname|cut -f2- -d.)
if [ $(ipa dnszone-show $zone 2>/dev/null | wc -l) -eq 0 ]; then
ipa dnszone-add --name-server=$master --admin-email=root.$master
fi
ptrzone=$(echo $ipaddress|awk -F. '{print $3 "." $2 "." $1 ".in-addr.arpa."}')
if [ $(ipa dnszone-show $ptrzone 2>/dev/null|wc -l) -eq 0 ]; then
ipa dnszone-add $ptrzone --name-server=$master --admin-email=root.$master
fi
# Now create this entry
ipa host-add $hostname --ip-address=$ipaddress
ipa host-show $hostname
done
This can be run for a given NIS domain:
[root@nis-server ~]# kinit admin [root@nis-server ~]# ./nis-hosts.sh nisdomain nis-master.example.com
Note
This script example does not account for special host scenarios, such as using aliases.
13.5.3.4. Importing Netgroup Entries
The
/etc/netgroup file contains all of the NIS netgroup information. These entries can be used to create IdM netgroup accounts that mirror the NIS entries.
For example, this is
nis-netgroup.sh:
#!/bin/sh
# 1 is the nis domain, 2 is the nis master server
ypcat -k -d $1 -h $2 netgroup > /dev/shm/nis-map.netgroup 2>&1
IFS=$'\n'
for line in $(cat /dev/shm/nis-map.netgroup); do
IFS=' '
netgroupname=$(echo $line|awk '{print $1}')
triples=$(echo $line|sed "s/^$netgroupname //")
echo "ipa netgroup-add $netgroupname --desc=NIS_NG_$netgroupname"
if [ $(echo $line|grep "(,"|wc -l) -gt 0 ]; then
echo "ipa netgroup-mod $netgroupname --hostcat=all"
fi
if [ $(echo $line|grep ",,"|wc -l) -gt 0 ]; then
echo "ipa netgroup-mod $netgroupname --usercat=all"
fi
for triple in $triples; do
triple=$(echo $triple|sed -e 's/-//g' -e 's/(//' -e 's/)//')
if [ $(echo $triple|grep ",.*,"|wc -l) -gt 0 ]; then
hostname=$(echo $triple|cut -f1 -d,)
username=$(echo $triple|cut -f2 -d,)
domain=$(echo $triple|cut -f3 -d,)
hosts=""; users=""; doms="";
[ -n "$hostname" ] && hosts="--hosts=$hostname"
[ -n "$username" ] && users="--users=$username"
[ -n "$domain" ] && doms="--nisdomain=$domain"
echo "ipa netgroup-add-member $hosts $users $doms"
else
netgroup=$triple
echo "ipa netgroup-add $netgroup --desc=NIS_NG_$netgroup"
fi
done
done
As explained briefly in Section 13.1, “About NIS and Identity Management”, NIS entries exist in a set of three values, called a triple. The triple is host,user,domain, but not every component is required; commonly, a triple only defines a host and domain or user and domain. The way this script is written, the
ipa netgroup-add-member command always adds a host, user, and domain triple to the netgroup.
if [ $(echo $triple|grep ",.*,"|wc -l) -gt 0 ]; then
hostname=$(echo $triple|cut -f1 -d,)
username=$(echo $triple|cut -f2 -d,)
domain=$(echo $triple|cut -f3 -d,)
hosts=""; users=""; doms="";
[ -n "$hostname" ] && hosts="--hosts=$hostname"
[ -n "$username" ] && users="--users=$username"
[ -n "$domain" ] && doms="--nisdomain=$domain"
echo "ipa netgroup-add-member $hosts $users $doms"
Any missing element is added as a blank, so the triple is properly migrated. For example, for the triple
server,,domain the options with the member add command are --hosts=server --users="" --nisdomain=domain.
This can be run for a given NIS domain by specifying the NIS domain and NIS server:
[root@nis-server ~]# kinit admin [root@nis-server ~]# ./nis-hosts.sh nisdomain nis-master.example.com
13.5.3.5. Importing Automount Maps
Automount maps are actually a series of nested and inter-related entries that define the location (the parent entry), and then associated keys and maps.
While the data are the same in the NIS and IdM entries, the way that data are defined is different. The NIS information is exported and then used to construct an LDAP entry for the automount location and associated map; it then creates an entry for every configured key for the map.
Unlike the other NIS migration script examples, this script takes options to create an automount location and a map name, along with the migrated NIS domain and server.
#!/bin/sh
# 1 is for the automount entry in ipa
ipa automountlocation-add $1
# 2 is the nis domain, 3 is the nis master server, 4 is the map name
ypcat -k -d $2 -h $3 $4 > /dev/shm/nis-map.$4 2>&1
ipa automountmap-add $1 $4
basedn=$(ipa env basedn|tr -d '[:space:]'|cut -f2 -d:)
cat > /tmp/amap.ldif <<EOF
dn: nis-domain=nisdomain.example.com+nis-map=$4,cn=NIS Server,cn=plugins,cn=config
objectClass: extensibleObject
nis-domain: $3
nis-map: $4
nis-base: automountmapname=$4,cn=nis,cn=automount,$basedn
nis-filter: (objectclass=*)
nis-key-format: %{automountKey}
nis-value-format: %{automountInformation}
EOF
ldapadd -x -h $3 -D "cn=directory manager" -w secret -f /tmp/amap.ldif
IFS=$'\n'
for line in $(cat /dev/shm/nis-map.$4); do
IFS=" "
key=$(echo "$line" | awk '{print $1}')
info=$(echo "$line" | sed -e "s#^$key[ \t]*##")
ipa automountkey-add nis $4 --key="$key" --info="$info"
done
This can be run for a given NIS domain:
[root@nis-server ~]# kinit admin [root@nis-server ~]# ./nis-hosts.sh location nisdomain nis-master.example.com map
13.5.4. Setting Weak Password Encryption for NIS User Authentication to IdM
A NIS server can handle CRYPT password hashes. Once an existing NIS server is migrated to IdM (and its underlying LDAP database), it may still be necessary to preserve the NIS-supported CRYPT passwords. However, the LDAP server does not use CRYPT hashes by default. It uses salted SHA (SSHA) or SSHA-256. If the 389 Directory Server password hash is not changed, then NIS users cannot authenticate to the IdM domain, and
kinit fails with password failures.
To set the underlying 389 Directory Server to use CRYPT as the password hash, change the
passwordStorageScheme attribute using ldapmodify:
[root@server ~]# ldapmodify -D "cn=directory server" -w secret -p 389 -h ipaserver.example.com dn: cn=config changetype: modify replace: passwordStorageScheme passwordStorageScheme: crypt
Note
Changing the password storage scheme only applies the scheme to new passwords; it does not retroactively change the encryption method used for existing passwords.
If weak crypto is required for password hashes, it is better to change the setting as early as possible so that more user passwords use the weaker password hash.
