Using external Red Hat utilities with Identity Management
Integrating services and Red Hat products in IdM
초록
Providing feedback on Red Hat documentation 링크 복사링크가 클립보드에 복사되었습니다!
We appreciate your feedback on our documentation. Let us know how we can improve it.
Submitting feedback through Jira (account required)
- Log in to the Jira website.
- Click Create in the top navigation bar
- Enter a descriptive title in the Summary field.
- Enter your suggestion for improvement in the Description field. Include links to the relevant parts of the documentation.
- Click Create at the bottom of the dialogue.
1장. IdM integration with Red Hat products 링크 복사링크가 클립보드에 복사되었습니다!
Find documentation for other Red Hat products that integrate with IdM. You can configure these products to allow your IdM users to access their services.
2장. Using external identity providers to authenticate to IdM 링크 복사링크가 클립보드에 복사되었습니다!
You can associate users with external identity providers (IdP) that support the OAuth 2 device authorization flow.
When these users authenticate with the SSSD they receive RHEL Identity Management (IdM) single sign-on capabilities with Kerberos tickets after performing authentication and authorization at the external IdP.
Notable features include:
-
Adding, modifying, and deleting references to external IdPs with
ipa idp-*commands. Enabling IdP authentication for users with the
ipa user-mod --user-auth-type=idpcommand.- What is supported
-
Logging in remotely via SSH with the
keyboard-interactiveauthentication method enabled, which allows calling Pluggable Authentication Module (PAM) libraries. -
Logging in locally with the console via the
logindservice. Retrieving a Kerberos ticket-granting ticket (TGT) with the
kinitutility.- What is currently not supported
- Logging in to the IdM WebUI directly. To log in to the IdM WebUI, you must first acquire a Kerberos ticket.
- Logging in to Cockpit WebUI directly. To log in to the Cockpit WebUI, you must first acquire a Kerberos ticket.
2.1. The benefits of connecting IdM to an external IdP 링크 복사링크가 클립보드에 복사되었습니다!
As an administrator, you might want to allow users stored in an external identity source, such as a cloud services provider, to access RHEL systems joined to your Identity Management (IdM) environment. To achieve this, you can delegate the authentication and authorization process of issuing Kerberos tickets for these users to that external entity.
You can use this feature to expand IdM’s capabilities and allow users stored in external identity providers (IdPs) to access Linux systems managed by IdM.
2.2. How IdM incorporates logins via external IdPs 링크 복사링크가 클립보드에 복사되었습니다!
SSSD 2.7.0 contains the sssd-idp package, which implements the idp Kerberos pre-authentication method. This authentication method follows the OAuth 2.0 Device Authorization Grant flow to delegate authorization decisions to external IdPs:
-
An IdM client user initiates OAuth 2.0 Device Authorization Grant flow, for example, by attempting to retrieve a Kerberos TGT with the
kinitutility at the command line. - A special code and website link are sent from the Authorization Server to the IdM KDC backend.
- The IdM client displays the link and the code to the user. In this example, the IdM client outputs the link and code on the command line.
The user opens the website link in a browser, which can be on another host, a mobile phone, and so on:
- The user enters the special code.
- If necessary, the user logs in to the OAuth 2.0-based IdP.
- The user is prompted to authorize the client to access information.
- The user confirms access at the original device prompt. In this example, the user hits the Enter key at the command line.
- The IdM KDC backend polls the OAuth 2.0 Authorization Server for access to user information.
2.3. Creating a reference to an external identity provider 링크 복사링크가 클립보드에 복사되었습니다!
To connect external identity providers (IdPs) to your Identity Management (IdM) environment, create IdP references in IdM. Complete this procedure to create a reference called my-keycloak-idp to an IdP based on the Keycloak template. For more reference templates, see Example references to different external IdPs in IdM.
Prerequisites
- You have registered IdM as an OAuth application to your external IdP, and obtained a client ID.
- You can authenticate as the IdM admin account.
Procedure
Authenticate as the IdM admin on an IdM server.
[root@server ~]# kinit adminCreate a reference called
my-keycloak-idpto an IdP based on the Keycloak template, where the--base-urloption specifies the URL to the Keycloak server in the formatserver-name.$DOMAIN:$PORT/prefix.[root@server ~]# ipa idp-add my-keycloak-idp \ --provider keycloak --organization main \ --base-url keycloak.idm.example.com:8443/auth \ --client-id id13778 ------------------------------------------------ Added Identity Provider reference "my-keycloak-idp" ------------------------------------------------ Identity Provider reference name: my-keycloak-idp Authorization URI: https://keycloak.idm.example.com:8443/auth/realms/main/protocol/openid-connect/auth Device authorization URI: https://keycloak.idm.example.com:8443/auth/realms/main/protocol/openid-connect/auth/device Token URI: https://keycloak.idm.example.com:8443/auth/realms/main/protocol/openid-connect/token User info URI: https://keycloak.idm.example.com:8443/auth/realms/main/protocol/openid-connect/userinfo Client identifier: ipa_oidc_client Scope: openid email External IdP user identifier attribute: email
Verification
Verify that the output of the
ipa idp-showcommand shows the IdP reference you have created.[root@server ~]# ipa idp-show my-keycloak-idp
2.4. Example references to different external IdPs in IdM 링크 복사링크가 클립보드에 복사되었습니다!
The following table lists examples of the ipa idp-add command for creating references to different IdPs in IdM.
| Identity Provider | Important options | Command example |
|---|---|---|
| Microsoft Identity Platform, Azure AD |
|
|
| |
|
|
| GitHub |
|
|
| Keycloak, Red Hat Single Sign-On |
|
참고
The Quarkus version of Keycloak 17 and later have removed the |
| Okta |
|
|
2.5. Options for the ipa idp-* commands to manage external identity providers in IdM 링크 복사링크가 클립보드에 복사되었습니다!
The following examples show how to configure references to external IdPs based on the different IdP templates. Use the following options to specify your settings:
--provider- the predefined template for one of the known identity providers
--client-id- the OAuth 2.0 client identifier issued by the IdP during application registration. As the application registration procedure is specific to each IdP, refer to their documentation for details. If the external IdP is Red Hat Single Sign-On (SSO), see Creating an OpenID Connect Client.
--base-url- base URL for IdP templates, required by Keycloak and Okta
--organization- Domain or Organization ID from the IdP, required by Microsoft Azure
--secret- (optional) Use this option if you have configured your external IdP to require a secret from confidential OAuth 2.0 clients. If you use this option when creating an IdP reference, you are prompted for the secret interactively. Protect the client secret as a password.
2.6. Managing references to external IdPs 링크 복사링크가 클립보드에 복사되었습니다!
After you have created a reference to an external identity provider (IdP), you can find, show, modify, and delete that reference. This example shows you how to manage a reference to an external IdP named keycloak-server1.
Prerequisites
- You can authenticate as the IdM admin account.
- You have created a reference to an external IdP in IdM. See Creating a reference to an external identity provider.
Procedure
Authenticate as the IdM admin on an IdM server.
[root@server ~]# kinit adminManage the IdP reference.
To find an IdP reference whose entry includes the string
keycloak:[root@server ~]# ipa idp-find keycloakTo display an IdP reference named
my-keycloak-idp:[root@server ~]# ipa idp-show my-keycloak-idpTo modify an IdP reference, use the
ipa idp-modcommand. For example, to change the secret for an IdP reference namedmy-keycloak-idp, specify the--secretoption to be prompted for the secret:[root@server ~]# ipa idp-mod my-keycloak-idp --secretTo delete an IdP reference named
my-keycloak-idp:[root@server ~]# ipa idp-del my-keycloak-idp
2.7. Enabling an IdM user to authenticate via an external IdP 링크 복사링크가 클립보드에 복사되었습니다!
To enable an IdM user to authenticate via an external identity provider (IdP), associate the external IdP reference you have previously created with the user account. This example associates the external IdP reference keycloak-server1 with the user idm-user-with-external-idp.
Prerequisites
- You have created a reference to an external IdP in IdM. See Creating a reference to an external identity provider.
Procedure
Modify the IdM user entry to associate an IdP reference with the user account:
[root@server ~]# ipa user-mod idm-user-with-external-idp \ --idp my-keycloak-idp \ --idp-user-id idm-user-with-external-idp@idm.example.com \ --user-auth-type=idp --------------------------------- Modified user "idm-user-with-external-idp" --------------------------------- User login: idm-user-with-external-idp First name: Test Last name: User1 Home directory: /home/idm-user-with-external-idp Login shell: /bin/sh Principal name: idm-user-with-external-idp@idm.example.com Principal alias: idm-user-with-external-idp@idm.example.com Email address: idm-user-with-external-idp@idm.example.com UID: 35000003 GID: 35000003 User authentication types: idp External IdP configuration: keycloak External IdP user identifier: idm-user-with-external-idp@idm.example.com Account disabled: False Password: False Member of groups: ipausers Kerberos keys available: False
Verification
Verify that the output of the
ipa user-showcommand for that user displays references to the IdP:[root@server ~]# ipa user-show idm-user-with-external-idp User login: idm-user-with-external-idp First name: Test Last name: User1 Home directory: /home/idm-user-with-external-idp Login shell: /bin/sh Principal name: idm-user-with-external-idp@idm.example.com Principal alias: idm-user-with-external-idp@idm.example.com Email address: idm-user-with-external-idp@idm.example.com ID: 35000003 GID: 35000003 User authentication types: idp External IdP configuration: keycloak External IdP user identifier: idm-user-with-external-idp@idm.example.com Account disabled: False Password: False Member of groups: ipausers Kerberos keys available: False
2.8. Retrieving an IdM ticket-granting ticket as an external IdP user 링크 복사링크가 클립보드에 복사되었습니다!
If you have delegated authentication for an Identity Management (IdM) user to an external identity provider (IdP), the IdM user can request a Kerberos ticket-granting ticket (TGT) by authenticating to the external IdP.
Complete this procedure to:
- Retrieve and store an anonymous Kerberos ticket locally.
-
Request the TGT for the idm-user-with-external-idp user by using
kinitwith the-Toption to enable Flexible Authentication via Secure Tunneling (FAST) channel to provide a secure connection between the Kerberos client and Kerberos Distribution Center (KDC).
Prerequisites
- You have created a reference to an external IdP in IdM. See Creating a reference to an external identity provider.
- You have associated an external IdP reference with the user account. See Enabling an IdM user to authenticate via an external IdP.
- The user that you are initially logged in as has write permissions on a directory in the local filesystem.
Procedure
Use Anonymous PKINIT to obtain a Kerberos ticket and store it in a file named
./fast.ccache.$ kinit -n -c ./fast.ccacheOptional: View the retrieved ticket:
$ klist -c fast.ccache Ticket cache: FILE:fast.ccache Default principal: WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS Valid starting Expires Service principal 03/03/2024 13:36:37 03/04/2024 13:14:28 krbtgt/IDM.EXAMPLE.COM@IDM.EXAMPLE.COMBegin authenticating as the IdM user, using the
-Toption to enable the FAST communication channel.[root@client ~]# kinit -T ./fast.ccache idm-user-with-external-idp Authenticate at https://oauth2.idp.com:8443/auth/realms/master/device?user_code=YHMQ-XKTL and press ENTER.:- In a browser, authenticate as the user at the website provided in the command output.
- At the command line, press the Enter key to finish the authentication process.
Verification
Display your Kerberos ticket information and confirm that the line
config: pa_typeshows152for pre-authentication with an external IdP.[root@client ~]# klist -C Ticket cache: KCM:0:58420 Default principal: idm-user-with-external-idp@IDM.EXAMPLE.COM Valid starting Expires Service principal 05/09/22 07:48:23 05/10/22 07:03:07 krbtgt/IDM.EXAMPLE.COM@IDM.EXAMPLE.COM config: fast_avail(krbtgt/IDM.EXAMPLE.COM@IDM.EXAMPLE.COM) = yes 08/17/2022 20:22:45 08/18/2022 20:22:43 krbtgt/IDM.EXAMPLE.COM@IDM.EXAMPLE.COM config: pa_type(krbtgt/IDM.EXAMPLE.COM@IDM.EXAMPLE.COM) = 152The
pa_type = 152indicates external IdP authentication.
2.9. Logging in to an IdM client via SSH as an external IdP user 링크 복사링크가 클립보드에 복사되었습니다!
To log in to an IdM client via SSH as an external identity provider (IdP) user, begin the login process on the command linel. When prompted, perform the authentication process at the website associated with the IdP, and finish the process at the Identity Management (IdM) client.
Prerequisites
- You have created a reference to an external IdP in IdM. See Creating a reference to an external identity provider.
- You have associated an external IdP reference with the user account. See Enabling an IdM user to authenticate via an external IdP.
Procedure
Attempt to log in to the IdM client via SSH.
[user@client ~]$ ssh idm-user-with-external-idp@client.idm.example.com (idm-user-with-external-idp@client.idm.example.com) Authenticate at https://oauth2.idp.com:8443/auth/realms/main/device?user_code=XYFL-ROYR and press ENTER.- In a browser, authenticate as the user at the website provided in the command output.
- At the command line, press the Enter key to finish the authentication process.
Verification
Display your Kerberos ticket information and confirm that the line
config: pa_typeshows152for pre-authentication with an external IdP.[idm-user-with-external-idp@client ~]$ klist -C Ticket cache: KCM:0:58420 Default principal: idm-user-with-external-idp@IDM.EXAMPLE.COM Valid starting Expires Service principal 05/09/22 07:48:23 05/10/22 07:03:07 krbtgt/IDM.EXAMPLE.COM@IDM.EXAMPLE.COM config: fast_avail(krbtgt/IDM.EXAMPLE.COM@IDM.EXAMPLE.COM) = yes 08/17/2022 20:22:45 08/18/2022 20:22:43 krbtgt/IDM.EXAMPLE.COM@IDM.EXAMPLE.COM config: pa_type(krbtgt/IDM.EXAMPLE.COM@IDM.EXAMPLE.COM) = 152
2.10. The --provider option in the ipa idp-* commands 링크 복사링크가 클립보드에 복사되었습니다!
The following identity providers (IdPs) support OAuth 2.0 device authorization grant flow:
- Microsoft Identity Platform, including Azure AD
- GitHub
- Keycloak, including Red Hat Single Sign-On (SSO)
- Okta
When using the ipa idp-add command to create a reference to one of these external IdPs, you can specify the IdP type with the --provider option, which expands into additional options as described below:
--provider=microsoftMicrosoft Azure IdPs allow parametrization based on the Azure tenant ID, which you can specify with the
--organizationoption to theipa idp-addcommand. If you need support for the live.com IdP, specify the option--organization common.Choosing
--provider=microsoftexpands to use the following options. The value of the--organizationoption replaces the string${ipaidporg}in the table.Expand Option Value --auth-uri=URIhttps://login.microsoftonline.com/${ipaidporg}/oauth2/v2.0/authorize--dev-auth-uri=URIhttps://login.microsoftonline.com/${ipaidporg}/oauth2/v2.0/devicecode--token-uri=URIhttps://login.microsoftonline.com/${ipaidporg}/oauth2/v2.0/token--userinfo-uri=URIhttps://graph.microsoft.com/oidc/userinfo--keys-uri=URIhttps://login.microsoftonline.com/common/discovery/v2.0/keys--scope=STRopenid email--idp-user-id=STRemail--provider=googleChoosing
--provider=googleexpands to use the following options:Expand Option Value --auth-uri=URIhttps://accounts.google.com/o/oauth2/auth--dev-auth-uri=URIhttps://oauth2.googleapis.com/device/code--token-uri=URIhttps://oauth2.googleapis.com/token--userinfo-uri=URIhttps://openidconnect.googleapis.com/v1/userinfo--keys-uri=URIhttps://www.googleapis.com/oauth2/v3/certs--scope=STRopenid email--idp-user-id=STRemail--provider=githubChoosing
--provider=githubexpands to use the following options:Expand Option Value --auth-uri=URIhttps://github.com/login/oauth/authorize--dev-auth-uri=URIhttps://github.com/login/device/code--token-uri=URIhttps://github.com/login/oauth/access_token--userinfo-uri=URIhttps://openidconnect.googleapis.com/v1/userinfo--keys-uri=URIhttps://api.github.com/user--scope=STRuser--idp-user-id=STRlogin--provider=keycloakWith Keycloak, you can define multiple realms or organizations. Since it is often a part of a custom deployment, both base URL and realm ID are required, and you can specify them with the
--base-urland--organizationoptions to theipa idp-addcommand:[root@client ~]# ipa idp-add MySSO --provider keycloak \ --org main --base-url keycloak.domain.com:8443/auth \ --client-id <your-client-id>Choosing
--provider=keycloakexpands to use the following options. The value you specify in the--base-urloption replaces the string${ipaidpbaseurl}in the table, and the value you specify for the--organization `option replaces the string `${ipaidporg}.Expand Option Value --auth-uri=URIhttps://${ipaidpbaseurl}/realms/${ipaidporg}/protocol/openid-connect/auth--dev-auth-uri=URIhttps://${ipaidpbaseurl}/realms/${ipaidporg}/protocol/openid-connect/auth/device--token-uri=URIhttps://${ipaidpbaseurl}/realms/${ipaidporg}/protocol/openid-connect/token--userinfo-uri=URIhttps://${ipaidpbaseurl}/realms/${ipaidporg}/protocol/openid-connect/userinfo--scope=STRopenid email--idp-user-id=STRemail--provider=oktaAfter registering a new organization in Okta, a new base URL is associated with it. You can specify this base URL with the
--base-urloption to theipa idp-addcommand:[root@client ~]# ipa idp-add MyOkta --provider okta --base-url dev-12345.okta.com --client-id <your-client-id>Choosing
--provider=oktaexpands to use the following options. The value you specify for the--base-urloption replaces the string${ipaidpbaseurl}in the table.Expand Option Value --auth-uri=URIhttps://${ipaidpbaseurl}/oauth2/v1/authorize--dev-auth-uri=URIhttps://${ipaidpbaseurl}/oauth2/v1/device/authorize--token-uri=URIhttps://${ipaidpbaseurl}/oauth2/v1/token--userinfo-uri=URIhttps://${ipaidpbaseurl}/oauth2/v1/userinfo--scope=STRopenid email--idp-user-id=STRemail
3장. Setting up Samba on an IdM domain member 링크 복사링크가 클립보드에 복사되었습니다!
You can set up Samba on a host that is joined to a Red Hat Identity Management (IdM) domain. Users from IdM and also, if available, from trusted Active Directory (AD) domains, can access shares and printer services provided by Samba.
Using Samba on an IdM domain member is an unsupported Technology Preview feature and contains certain limitations. For example, IdM trust controllers do not support the Active Directory Global Catalog service, and they do not support resolving IdM groups using the Distributed Computing Environment / Remote Procedure Calls (DCE/RPC) protocols. As a consequence, AD users can only access Samba shares and printers hosted on IdM clients when logged in to other IdM clients; AD users logged into a Windows machine cannot access Samba shares hosted on an IdM domain member.
Customers deploying Samba on IdM domain members are encouraged to provide feedback to Red Hat.
If users from AD domains need to access shares and printer services provided by Samba, ensure the AES encryption type is enabled is AD. For more information, see Enabling the AES encryption type in Active Directory using a GPO.
3.1. Prerequisites 링크 복사링크가 클립보드에 복사되었습니다!
- The host is joined as a client to the IdM domain.
- Both the IdM servers and the client must run on RHEL 10.
3.2. Preparing the IdM domain for installing Samba on domain members 링크 복사링크가 클립보드에 복사되었습니다!
Before you can set up Samba on an IdM client, you must prepare the IdM domain using the ipa-adtrust-install utility on an IdM server.
Any system where you run the ipa-adtrust-install command automatically becomes an AD trust controller. However, you must run ipa-adtrust-install only once on an IdM server.
Prerequisites
- IdM server is installed.
- You have root privileges to install packages and restart IdM services.
Procedure
Install the required packages:
[root@ipaserver ~]# dnf install ipa-server-trust-ad samba-clientAuthenticate as the IdM administrative user:
[root@ipaserver ~]# kinit adminRun the
ipa-adtrust-installutility:[root@ipaserver ~]# ipa-adtrust-installThe DNS service records are created automatically if IdM was installed with an integrated DNS server.
If you installed IdM without an integrated DNS server,
ipa-adtrust-installprints a list of service records that you must manually add to DNS before you can continue.The script prompts you that the
/etc/samba/smb.confalready exists and will be rewritten:WARNING: The smb.conf already exists. Running ipa-adtrust-install will break your existing Samba configuration. Do you wish to continue? [no]: yesThe script prompts you to configure the
slapi-nisplug-in, a compatibility plug-in that allows older Linux clients to work with trusted users:Do you want to enable support for trusted domains in Schema Compatibility plugin? This will allow clients older than SSSD 1.9 and non-Linux clients to work with trusted users. Enable trusted domains support in slapi-nis? [no]: yesYou are prompted to run the SID generation task to create a SID for any existing users:
Do you want to run the ipa-sidgen task? [no]: yesThis is a resource-intensive task, so if you have a high number of users, you can run this at another time.
Optional: By default, the Dynamic RPC port range is defined as
49152-65535for Windows Server 2008 and later. If you need to define a different Dynamic RPC port range for your environment, configure Samba to use different ports and open those ports in your firewall settings. The following example sets the port range to55000-65000.[root@ipaserver ~]# net conf setparm global 'rpc server dynamic port range' 55000-65000 [root@ipaserver ~]# firewall-cmd --add-port=55000-65000/tcp [root@ipaserver ~]# firewall-cmd --runtime-to-permanentRestart the
ipaservice:[root@ipaserver ~]# ipactl restartUse the
smbclientutility to verify that Samba responds to Kerberos authentication from the IdM side:[root@ipaserver ~]# smbclient -L ipaserver.idm.example.com -U user_name --use-kerberos=required lp_load_ex: changing to config backend registry Sharename Type Comment --------- ---- ------- IPC$ IPC IPC Service (Samba 4.15.2) ...
3.3. Installing and configuring a Samba server on an IdM client 링크 복사링크가 클립보드에 복사되었습니다!
You can install and configure Samba on an IdM client to securely share files with integrated authentication, leveraging IdM domain accounts for access. Ensure proper prerequisites and configuration to enable seamless resource sharing across your network.
Prerequisites
- Both the IdM servers and the client must run on RHEL 10 or later.
- The IdM domain is prepared as described in Preparing the IdM domain for installing Samba on domain members.
- If IdM has a trust configured with AD, enable the AES encryption type for Kerberos. For example, use a group policy object (GPO) to enable the AES encryption type. For details, see Enabling AES encryption in Active Directory using a GPO.
Procedure
Install the
ipa-client-sambapackage:[root@idm_client]# dnf install ipa-client-sambaUse the
ipa-client-sambautility to prepare the client and create an initial Samba configuration:[root@idm_client]# ipa-client-samba Searching for IPA server... IPA server: DNS discovery Chosen IPA master: idm_server.idm.example.com SMB principal to be created: cifs/idm_client.idm.example.com@IDM.EXAMPLE.COM NetBIOS name to be used: IDM_CLIENT Discovered domains to use: Domain name: idm.example.com NetBIOS name: IDM SID: S-1-5-21-525930803-952335037-206501584 ID range: 212000000 - 212199999 Domain name: ad.example.com NetBIOS name: AD SID: None ID range: 1918400000 - 1918599999 Continue to configure the system with these values? [no]: yes Samba domain member is configured. Please check configuration at /etc/samba/smb.conf and start smb and winbind servicesBy default,
ipa-client-sambaautomatically adds the[homes]section to the/etc/samba/smb.conffile that dynamically shares a user’s home directory when the user connects. If users do not have home directories on this server, or if you do not want to share them, remove the following lines from/etc/samba/smb.conf:[homes] read only = noShare directories and printers. For details, see:
Open the ports required for a Samba client in the local firewall:
[root@idm_client]# firewall-cmd --permanent --add-service=samba-client [root@idm_client]# firewall-cmd --reloadEnable and start the
smbandwinbindservices:[root@idm_client]# systemctl enable --now smb winbind
Verification
Run the following verification step on a different IdM domain member that has the samba-client package installed:
List the shares on the Samba server using Kerberos authentication:
$ smbclient -L idm_client.idm.example.com -U user_name --use-kerberos=required lp_load_ex: changing to config backend registry Sharename Type Comment --------- ---- ------- example Disk IPC$ IPC IPC Service (Samba 4.15.2) ...For more information, see the
ipa-client-samba(1)man page on your system.
3.4. Manually adding an ID mapping configuration if IdM trusts a new domain 링크 복사링크가 클립보드에 복사되었습니다!
Samba requires an ID mapping configuration for each domain from which users access resources. On an existing Samba server running on an IdM client, you must manually add an ID mapping configuration after the administrator added a new trust to an Active Directory (AD) domain.
Prerequisites
- You configured Samba on an IdM client. Afterward, a new trust was added to IdM.
- The DES and RC4 encryption types for Kerberos must be disabled in the trusted AD domain. For security reasons, RHEL 10 does not support these weak encryption types.
Procedure
Authenticate using the host’s keytab:
[root@idm_client]# kinit -kUse the
ipa idrange-findcommand to display both the base ID and the ID range size of the new domain. For example, the following command displays the values for thead.example.comdomain:[root@idm_client]# ipa idrange-find --name="AD.EXAMPLE.COM_id_range" --raw --------------- 1 range matched --------------- cn: AD.EXAMPLE.COM_id_range ipabaseid: 1918400000 ipaidrangesize: 200000 ipabaserid: 0 ipanttrusteddomainsid: S-1-5-21-968346183-862388825-1738313271 iparangetype: ipa-ad-trust ---------------------------- Number of entries returned 1 ----------------------------You need the values from the
ipabaseidandipaidrangesizeattributes in the next steps.To calculate the highest usable ID, use the following formula:
maximum_range = ipabaseid + ipaidrangesize - 1With the values from the previous step, the highest usable ID for the
ad.example.comdomain is1918599999(1918400000 + 200000 - 1).Edit the
/etc/samba/smb.conffile, and add the ID mapping configuration for the domain to the[global]section:idmap config AD : range = 1918400000 - 1918599999 idmap config AD : backend = sssSpecify the value from
ipabaseidattribute as the lowest and the computed value from the previous step as the highest value of the range.Restart the
smbandwinbindservices:[root@idm_client]# systemctl restart smb winbind
Verification
List the shares on the Samba server using Kerberos authentication:
$ smbclient -L idm_client.idm.example.com -U user_name --use-kerberos=required lp_load_ex: changing to config backend registry Sharename Type Comment --------- ---- ------- example Disk IPC$ IPC IPC Service (Samba 4.15.2) ...
4장. Migrating from NIS to Identity Management 링크 복사링크가 클립보드에 복사되었습니다!
A Network Information Service (NIS) server can contain information about users, groups, hosts, netgroups and automount maps. As a system administrator you can migrate these entry types, authentication, and authorization from NIS server to an Identity Management (IdM) server so that all user management operations are performed on the IdM server. Migrating from NIS to IdM will also allow you access to more secure protocols such as Kerberos.
4.1. Enabling NIS in IdM 링크 복사링크가 클립보드에 복사되었습니다!
To allow communication between NIS and Identity Management (IdM) server, you must enable NIS compatibility options on IdM server.
Prerequisites
- You have root access on IdM server.
Procedure
Enable the NIS listener and compatibility plug-ins on IdM server:
[root@ipaserver ~]# ipa-nis-manage enable [root@ipaserver ~]# ipa-compat-manage enableOptional: For a more strict firewall configuration, set a fixed port.
For example, to set the port to unused port
514:[root@ipaserver ~]# ldapmodify -x -D 'cn=directory manager' -W dn: cn=NIS Server,cn=plugins,cn=config changetype: modify add: nsslapd-pluginarg0 nsslapd-pluginarg0: 514주의To avoid conflict with other services do not use any port number above 1024.
Enable and start the port mapper service:
[root@ipaserver ~]# systemctl enable rpcbind.service [root@ipaserver ~]# systemctl start rpcbind.serviceRestart Directory Server:
[root@ipaserver ~]# systemctl restart dirsrv.target
4.2. Migrating user entries from NIS to IdM 링크 복사링크가 클립보드에 복사되었습니다!
The NIS passwd map contains information about users, such as names, UIDs, primary group, GECOS, shell, and home directory. Use this data to migrate NIS user accounts to Identity Management (IdM):
Prerequisites
- You have root access on NIS server.
- NIS is enabled in IdM.
- The NIS server is enrolled into IdM.
- You have ID ranges that can store UIDs of importing users.
Procedure
Install the
yp-toolspackage:[root@nis-server ~]# dnf install yp-tools -yOn the NIS server create the
/root/nis-users.shscript with the following content:#!/bin/sh # $1 is the NIS domain, $2 is the primary NIS 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 doneAuthenticate as the IdM
adminuser:[root@nis-server ~]# kinit adminRun the script. For example:
[root@nis-server ~]# sh /root/nis-users.sh nisdomain nis-server.example.com중요This script uses hard-coded values for first name, last name, and sets the password to
passw0rd1. The user must change the temporary password at the next login.
4.3. Migrating user group from NIS to IdM 링크 복사링크가 클립보드에 복사되었습니다!
The NIS group map contains information about groups, such as group names, GIDs, or group members. Use this data to migrate NIS groups to Identity Management (IdM):
Prerequisites
- You have root access on NIS server.
- NIS is enabled in IdM.
- The NIS server is enrolled into IdM.
Procedure
Install the
yp-toolspackage:[root@nis-server ~]# dnf install yp-tools -yCreate the
/root/nis-groups.shscript with the following content on the NIS server:#!/bin/sh # $1 is the NIS domain, $2 is the primary NIS 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 useropts=$(eval echo --users={$members}) ipa group-add-member $groupname $useropts fi ipa group-show $groupname done참고Make sure your usernames do not contain any special characters to ensure successful migration of the user group.
Authenticate as the IdM
adminuser:[root@nis-server ~]# kinit adminRun the script. For example:
[root@nis-server ~]# sh /root/nis-groups.sh nisdomain nis-server.example.com
4.4. Migrating host entries from NIS to IdM 링크 복사링크가 클립보드에 복사되었습니다!
The NIS hosts map contains information about hosts, such as host names and IP addresses. Use this data to migrate NIS host entries to Identity Management (IdM):
When you create a host group in IdM, a corresponding shadow NIS group is automatically created. Do not use the ipa netgroup-* commands on these shadow NIS groups. Use the ipa netgroup-* commands only to manage native netgroups created via the netgroup-add command.
Prerequisites
- You have root access on NIS server.
- NIS is enabled in IdM.
- The NIS server is enrolled into IdM.
Procedure
Install the
yp-toolspackage:[root@nis-server ~]# dnf install yp-tools -yCreate the
/root/nis-hosts.shscript with the following content on the NIS server:#!/bin/sh # $1 is the NIS domain, $2 is the primary NIS 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}') primary=$(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=$primary --admin-email=root.$primary 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=$primary --admin-email=root.$primary fi # Now create this entry ipa host-add $hostname --ip-address=$ipaddress ipa host-show $hostname doneAuthenticate as the IdM
adminuser:[root@nis-server ~]# kinit adminRun the script. For example:
[root@nis-server ~]# sh /root/nis-hosts.sh nisdomain nis-server.example.com참고This script does not migrate special host configurations, such as aliases.
4.5. Migrating netgroup entries from NIS to IdM 링크 복사링크가 클립보드에 복사되었습니다!
The NIS netgroup map contains information about netgroups. Use this data to migrate NIS netgroups to Identity Management (IdM):
Prerequisites
- You have root access on NIS server.
- NIS is enabled in IdM.
- The NIS server is enrolled into IdM.
Procedure
Install the
yp-toolspackage:[root@nis-server ~]# dnf install yp-tools -yCreate the
/root/nis-netgroups.shscript with the following content on the NIS server:#!/bin/sh # $1 is the NIS domain, $2 is the primary NIS 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 $netgroup $hosts $users $doms" else netgroup=$triple echo "ipa netgroup-add $netgroup --desc=<NIS_NG>_$netgroup" fi done doneAuthenticate as the IdM
adminuser:[root@nis-server ~]# kinit adminRun the script. For example:
[root@nis-server ~]# sh /root/nis-netgroups.sh nisdomain nis-server.example.com
4.6. Migrating automount maps from NIS to IdM 링크 복사링크가 클립보드에 복사되었습니다!
Automount maps are a series of nested and interrelated entries that define the location (the parent entry), the associated keys, and maps. To migrate NIS automount maps to Identity Management (IdM):
Prerequisites
- You have root access on NIS server.
- NIS is enabled in IdM.
- The NIS server is enrolled into IdM.
Procedure
Install the
yp-toolspackage:[root@nis-server ~]# dnf install yp-tools -yCreate the
/root/nis-automounts.shscript with the following content on the NIS server:#!/bin/sh # $1 is for the automount entry in ipa ipa automountlocation-add $1 # $2 is the NIS domain, $3 is the primary NIS 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=$2+nis-map=$4,cn=NIS Server,cn=plugins,cn=config objectClass: extensibleObject nis-domain: $2 nis-map: $4 nis-base: automountmapname=$4,cn=$1,cn=automount,$basedn nis-filter: (objectclass=\*) nis-key-format: %{automountKey} nis-value-format: %{automountInformation} EOF # $5 is the LDAP server ldapadd -x -h $5 -D "cn=Directory Manager" -W -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참고The script exports the NIS automount information, generates an LDAP Data Interchange Format (LDIF) for the automount location and associated map, and imports the LDIF file into the IdM Directory Server.
Authenticate as the IdM
adminuser:[root@nis-server ~]# kinit adminRun the script. For example:
[root@nis-server ~]# sh /root/nis-automounts.sh location nisdomain nis-server.example.com map_name