How to automate realm join command?
by Zdravko Zdravkov
Hi all.
I'm looking for the best way to automate the realm join command. Ideally
I'd achieve that in kickstart or at first login.
I've been considering some kind of shell script, but it seems that it will
work only when password is in plain text, which I want to to avoid if
possible.
Thanks for any suggestions
4 years, 8 months
System Error when su to user
by Sherman Lilly
I am getting an System Error message when I try to su to an user. I am
using Ubuntu 18.04 and version 1.16.1-1ubuntu1.3
Jul 29 11:55:17 su[8658]: pam_sss(su:auth): authentication success;
logname= uid=1000 euid=0 tty=/dev/pts/0 ruser=**** rhost= user=*****
Jul 29 11:55:17 su[8658]: pam_sss(su:account): Access denied for user
*****: 4 (System error)
Jul 29 11:55:17 su[8658]: pam_acct_mgmt: System error
Jul 29 11:55:17 su[8658]: FAILED su for ***** by *****
4 years, 8 months
Max hostname len in adcli or realm join to AD?
by Spike White
All,
In previous AD integration tools, the max host name length was customarily
15 chars. Because of ancient NETBIOS restrictions (16 char restrictions
and netbios adds a '$' to the end of host name).
That was like an AD 2003 restriction.
With some slightly (well-documented) trickiness, in newer AD deployments
those AD integration tools would allow up to an 18 char host name.
I see in modern AD now, up to a 20 character name is tolerated (although
recommendation is to retain the final '$'). So -- 19 char max.
https://social.technet.microsoft.com/Forums/en-US/f2afb2ce-74fb-4434-932b...
(However, that statement that 'common name' (max length 15) has to be
unique in the OU is troubling. If you put all your Linux servers in the
same OU, you're back to your 15 char limitation.)
Apparently, in 2013 realm join and adcli allowed a15 char host name max.
https://bugzilla.redhat.com/show_bug.cgi?id=1001667
Is that still true today, max 15 char host name in realm join / adcli?
Spike
4 years, 8 months
Replicate digest mapping from pam_pkcs11
by James Trater
Hello.
Is it possible to replicate the digest mapping feature of pam_pkcs11 in sssd? We have built our infrastructure around the notion of mapping users to certificates based on the certificate digest. With the removal of pam_pkcs11 from recent distros (including RHEL 8) we are faced with either changing our mapping scheme (potentially a lot of work) or making this work in sssd. This is a snippet of what we do today:
--- snip pam_pkcs11.conf ---
# digest - elaborate certificate digest and map it into a file
mapper digest {
debug = false;
module = internal;
# module = /usr/$LIB/pam_pkcs11/digest_mapper.so;
# algorithm used to evaluate certificate digest
# Select one of:
# "null","md2","md4","md5","sha","sha1","dss","dss1","ripemd160"
algorithm = "sha1";
mapfile = file:///etc/pam_pkcs11/digest_mapping;
# mapfile = "none";
}
--- snip ---
# snippet of digest_mapping file (the values have been obfuscated)
[root@friday-vm]# grep jim digest_mapping
11:BC:53:F1:EF:24:B4:9C:47:ED:7D:EC:2B:82:CB:93:61:F8:88:4F -> jim
4 years, 8 months
How to alleviate certain annoying messages in /var/log/messages?
by Spike White
sssd experts,
We have a “nuisance-level” problem with RHEL8 physical builds after
AD-integrating via sssd. How do I stop certain annoying messages in
/var/log/messages?
This RHEL8 physical build properly creates an /etc/krb5.keytab file with
the expected host entries. Here’s the snippet from kutil:
[root@austgcore25 log]# cd /etc
[root@austgcore25 etc]# ktutil
ktutil: read_kt /etc/krb5.keytab
ktutil: list -t -e -k
slot KVNO Timestamp Principal
---- ---- -----------------
---------------------------------------------------
…
6 16 07/03/2019 21:31 host/AUSTGCORE25(a)AMER.EXAMPLE.COM
(des-cbc-crc) (0xbf3d37462967e65e)
7 16 07/03/2019 21:31 host/AUSTGCORE25(a)AMER.EXAMPLE.COM
(des-cbc-md5) (0xbf3d37462967e65e)
8 16 07/03/2019 21:31 host/AUSTGCORE25(a)AMER.EXAMPLE.COM
(arcfour-hmac) (0xa21feefac524db9e82f3e38e73551c28)
9 16 07/03/2019 21:31 host/AUSTGCORE25(a)AMER.EXAMPLE.COM
(aes128-cts-hmac-sha1-96) (0x196ff6a33ef6284bb432f97cf36e737c)
10 16 07/03/2019 21:31 host/AUSTGCORE25(a)AMER.EXAMPLE.COM
(aes256-cts-hmac-sha1-96)
(0xadd866228352701a94f5cd40d76ed886a7fe084b2f7a90981b16d19f14962e3b)
…
The AD integration seems to work fine. I can log in with my AD account no
problem. Even after reboots. (cross domain authentication temporarily not
working on this build, likely unrelated.)
However, we continue to get the complaints in /var/log/messages:
Jul 8 11:38:25 austgcore25 [sssd[ldap_child[1816]]][1816]: Failed to
initialize credentials using keytab [MEMORY:/etc/krb5.keytab]: Client 'host/
AUSTGCORE25(a)AMER.EXAMPLE.COM' not found in Kerberos database. Unable to
create GSSAPI-encrypted LDAP connection.
Jul 8 11:38:26 austgcore25 [sssd[ldap_child[1817]]][1817]: Failed to
initialize credentials using keytab [MEMORY:/etc/krb5.keytab]: Client 'host/
AUSTGCORE25(a)AMER.EXAMPLE.COM' not found in Kerberos database. Unable to
create GSSAPI-encrypted LDAP connection.
I notice it’s attempting to use MEMORY:/etc/krb5.keytab.
How do I stop this annoying messages in /var/log/messages? We have multiple
AD domains defined in our sssd.conf file for this cross-domain auth. (Usually,
cross-domain auth works fine for us.)
Spike
4 years, 8 months
sssd sudo using Microsoft Active Directory
by Bruno Monteiro
Hello,
Below my configuration and errors :)
(I've adapted some strings for the sake of example - domain is not real)
cat /etc/sssd/sssd.conf
[sssd]
services = nss, pam,ssh, sudo
debug_level = 0x7FFF
domains = LDAP_MY.COM
[sudo]
debug_level = 0x3ff0
[domain/LDAP_MY.COM]
debug_level = 0x3ff0
access_provider = ldap
id_provider = ldap
sudo_provider = ldap
ldap_uri = ldap://<IP>
ldap_default_bind_dn = <user>@my.com
ldap_default_authtok = <password>
ldap_sudo_search_base = OU=SUDOers,DC=my,DC=com
/etc/nsswitch.conf
...
sudoers: sss files
....
ldbsearch -H /var/lib/sss/db/cache_LDAP_MY.COM/ldb contains Microsoft AD records:
# record 2
dn: name=r2,cn=sudorules,cn=custom,cn=LDAP_MY.COM,cn=sysdb
cn: r2
dataExpireTimestamp: 1561891358
entryUSN: 245385
name: r2
objectClass: sudoRule
originalDN: CN=r2,OU=SUDOers,DC=my,DC=com
sudoCommand: ALL
sudoHost: ALL
sudoOption: !authenticate
sudoUser: Admin(a)my.com
distinguishedName: name=r2,cn=sudorules,cn=custom,cn=LDAP_MY.COM,
cn=sysdb
AD sudoRole is sudoRule in local SSSD DB cache.
But getting this below when trying to test 'sudo -l' or 'sudo su'
[sssd[sudo]] [sudosrv_fetch_rules] (0x0400): Returning 0 rules for [Admin@my.com(a)my.com]
from /var/log/sssd/sssd_sudo.log
Duplicate domain ?
I can see the rules been updated in the SSSD cache file from Microsoft AD.
But I cannot use them because maybe some misconfiguration ?
setup for sudo logs:
/etc/sudo.conf and put down the following lines:
Debug sudo /var/log/sudo_debug all@debug
Debug sudoers.so /var/log/sudo_debug all@debug
from /var/log/sudo_debug I have this:
...
user_in_group: user admin(a)my.com NOT in group sudo
...
Thx a lot!
Cheers!
4 years, 9 months