0.Intro I decided to try a certain product at work and built an environment. It was my first time to join Linux to a domain, so I had a hard time not knowing what to do. In the product procedure
* This article is still in beta. After this, I plan to actually do a clean install of the machine and rebuild it from scratch. Editing may come in at that time. This is also my memorandum.
Let's assume that this is the environment. Of course AD Server is Windows Server. OS name: centos OS version: 8.3 Domain name: brains-mind.local Kerberos realm: BRAINS-MIND.LOCAL Domain Controller 1: ad1.brains-mind.local (10.120.X.X) Domain controller 2: ad2.brains-mind.local (10.65.X.X) FQDN of the machine to join: search.brains-mind.local Computer name: search User account for domain authentication (Domain Admin): my account
/etc/environment
http_proxy="http://10.120.X.XXX:9080"
HTTP_PROXY="http://10.120.X.XXX:9080"
https_proxy="http://10.120.X.XXX:9080"
HTTPS_PROXY="http://10.120.X.XXX:9080"
This time below
/etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
10.130.X.X search
10.120.X.X ad1.brains-mind.local
10.65.X.X ad2.brains-mind.local
/etc/resolv.conf
nameserver 10.120.X.X
nameserver 10.65.X.X
Also set dns to the port. It is the AD server to set
nmcli connection modify ens2 ipv4.dns 10.120.X.X
nmcli connection down ens2; nmcli connection up ens2
/etc/krb5.conf)
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
dns_lookup_realm = false
dns_lookup_kdc = true
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
rdns = false
pkinit_anchors = FILE:/etc/pki/tls/certs/ca-bundle.crt
spake_preauth_groups = edwards25519
default_realm = BRAINS-MIND.LOCAL
default_ccache_name = KEYRING:persistent:%{uid}
[realms]
BRAINS-MIND.LOCAL = {
kdc = brains-mind.local
admin_server = brains-mind.local
}
[domain_realm]
.brains-mind.local = BRAINS-MIND.LOCAL
brains-mind.local = BRAINS-MIND.LOCAL
adcli join -v --show-password --os-name = OS name --os-version = OS version -K /etc/krb5.keytab --service-name = host --service-name = HTTP -D domain name -R Kerberos realm (all uppercase) -S domain controller -H FQDN of the machine to join -N computer name -U user account for domain authentication
This time
adcli join -v --show-password --os-name=centos --os-version=8.3 -K /etc/krb5.keytab --service-name=host --service-name=HTTP -D brains-mind.local -R BRAINS-MIND.LOCAL -S ad1.brains-mind.local -H search.brains-mind.local -N search -U [email protected]
This is one of the reasons I was addicted to this time. krb5.keytab is generated by this command. I was having trouble checking various things such as having to generate it with an AD server, but it can be done with Linux on the client side. I was swayed a lot by krb5.keytab, which plays an important role. Whether the generated keytab is functioning properly and whether the domain participation is successful in the first place can be checked with commands such as kinit and klist -K.
/etc/sssd/sssd.conf
[sssd]
domains = brains-mind.local
config_file_version = 2
services = nss, pam,ssh
default_domain_suffix = brains-mind.local
[domain/brains-mind.local]
ad_domain = brains-mind.local
krb5_realm = BRAINS-MIND.LOCAL
debug_level = 5
id_provider = ad
auth_provider = ad
chpass_provider = ad
sudo_provider = ad
dyndns_update = false
ldap_schema = ad
ad_server = ad1.brains-mind.local,ad2.brains-mind.local
enumerate = false
ldap_id_mapping = true
use_fully_qualified_names = True
krb5_keytab = /etc/krb5.keytab
ldap_krb5_keytab = /etc/krb5.keytab
ldap_sasl_authid = [email protected]
default_shell=/bin/bash
override_homedir=/home/%u
[nss]
[ssh]
[pam]
This was the hardest part. The more you investigate whether it is a specification or a bug, the more you will not know. There is a wide variety of information on the internet, and I wonder which one is true. After all, I searched for it while glancing at the logs under/var/log/sssd/(I would say that originally w) The point here is
I think. For ldap_sasl_authid, the format is ldap_sasl_authid = (machine name) $ @ (domain name) is what they said.
Don't forget to set Permission after editing
sudo chmod 600 /etc/sssd/sssd.conf
sudo chown root:root /etc/sssd/sssd.conf
/etc/samba/smb.conf
[global]
workgroup = BRAINS-MIND
security = ads
realm = BRAINS-MIND.LOCAL
password server = *
template homedir = /home/%U
template shell = /bin/bash
kerberos method = secrets and keytab
client signing = yes
client use spnego = yes
log file = /var/log/samba/log.%m
Since the default description is not necessary at all, it seems that you can delete all and follow this description.
Reflect the previous settings in /etc/nsswitch.conf and PAM. I think you should take a quick look at PAM's /etc/pam.d/system-auth and /etc/pam.d/password-auth.
authconfig --enablesssd --enablesssdauth --enableforcelegacy --update
And service restart and registration
systemctl start sssd && systemctl enable sssd
This completes the settings.
First of all, whether it is actually working
id myaccount
Check if the information on your AD is pulled.
And
ssh myaccount@localhost
You can check if you can log in. If you log in successfully, you will have a folder in/home. In this case/home/myaccount is not it.
11.SSO
The product I wanted to verify this time was a browser-based SSO product. However, I could log in directly from CentOS or by ssh connection, but when I tried to open the product from the browser, an error occurred. Looking at the log
/var/log/httpd/error_log
[Fri Dec 25 15:07:58.337453 2020] [auth_gssapi:error] [pid 1797:tid 139985499928320] [client 10.130.XXX.XXX:53007] GSS ERROR In Negotiate Auth: gss_accept_sec_context() failed: [Unspecified GSS failure. Minor code may provide more information (Clock skew too great)]
[Fri Dec 25 15:07:59.770713 2020] [auth_gssapi:error] [pid 1797:tid 139985491535616] [client 10.130.XXX.XXX:53007] GSS ERROR In Negotiate Auth: gss_accept_sec_context() failed: [Unspecified GSS failure. Minor code may provide more information (Clock skew too great)]
[Fri Dec 25 15:08:00.527564 2020] [auth_gssapi:error] [pid 1797:tid 139985483142912] [client 10.130.XXX.XXX:53007] GSS ERROR In Negotiate Auth: gss_accept_sec_context() failed: [Unspecified GSS failure. Minor code may provide more information (Clock skew too great)]
And so on. "Clock skew too great" means that the time difference between AD Server and the Kerberos 5 client (CentOS) is 5 minutes or more. But when I look at the clock and the Date command, it doesn't open that much. The cause was timezone. AD Servert was JST and CentOS was UTC. In other words, CentOS was strange for 9 hours. (It's a mystery why I was able to log in, but w) After matching both timezones, SSO can be done safely. There was such a pitfall.
The following sites have greatly helped me in setting up so far. Thank you very much. Samba/Linux participation --Chaperone
Recommended Posts