adcli behavior change with RHEL 7.7
by Erinn Looney-Triggs
Previously when using adcli to join a RHEL <7.7 system to the AD principles came out in this format:
EXAMPLE$(a)AD.DOMAIN.COM
Now when doing a join with adcli we are getting principles in this format:
example$(a)AD.DOMAIN.COM
Is this still a legal NETBIOS name? I mean I know it can work, it is just a string from kerbs perspective, but I was under the impression that the AD was pretty specific about what it expected the host principle to be. I am still digging into this, but so far this has broken some of our kerb code and it appears to have broken adcli update as well because it is looking for the uppercase principle while only the lower case principle is available in the keytab.
Thanks,
-Erinn
4 years, 8 months
override_gid not applying to trusted/parent AD domains when joined via child
by Josh Snyder
Hi All,
I'm working in a proof of concept for a customer where I've been asked to
join the child domain of a Microsoft Active Directory domain,
child.example.com. Users will primarily exist in the parent, example.com,
but some users will also exist in the child. The application requires that
all users have a specific primary GID, 1100, which is defined in /etc/group
and I'm attempting to apply via override_gid.
User authentication via either the child or parent is successful, however,
the override_gid is only applied to users of the child, @child.example.com
and NOT for users of the parent, @example.com.
I saw what looked to be a similar post to this list from Sep 2018. It was
suggested this may be a bug. I didn't see a follow-up/resolution to that
thread. Is this issue being tracked or has it been resolved?
Below is my sssd.conf:
[root@linux2 sssd]# cat sssd.conf
[sssd]
domains = child.example.com
config_file_version = 2
services = nss, pam
default_domain_suffix = EXAMPLE.COM
[domain/child.example.com]
ad_domain = child.example.com
krb5_realm = CHILD.EXAMPLE.COM
realmd_tags = manages-system joined-with-samba
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = True
fallback_homedir = /home/%u@%d
access_provider = ad
ad_access_filter = FOREST:example.com:
(memberOf:1.2.840.113556.1.4.1941:=CN=LinuxUsers,ou=Groups,dc=child,dc=example,dc=com)
auth_provider = ad
chpass_provider = ad
ldap_schema = ad
override_gid = 1100
CentOS Version:
[root@linux2 sssd]# cat /etc/redhat-release
CentOS Linux release 7.5.1804 (Core)
SSSD Component Versions:
[root@linux2 sssd]# rpm -qa |grep sssd
sssd-common-pac-1.16.2-13.el7_6.8.x86_64
sssd-ldap-1.16.2-13.el7_6.8.x86_64
python-sssdconfig-1.16.2-13.el7_6.8.noarch
sssd-client-1.16.2-13.el7_6.8.x86_64
sssd-krb5-common-1.16.2-13.el7_6.8.x86_64
sssd-ipa-1.16.2-13.el7_6.8.x86_64
sssd-krb5-1.16.2-13.el7_6.8.x86_64
sssd-dbus-1.16.2-13.el7_6.8.x86_64
sssd-proxy-1.16.2-13.el7_6.8.x86_64
sssd-tools-1.16.2-13.el7_6.8.x86_64
sssd-common-1.16.2-13.el7_6.8.x86_64
sssd-ad-1.16.2-13.el7_6.8.x86_64
sssd-1.16.2-13.el7_6.8.x86_64
Thanks,
-Josh
4 years, 8 months
[AD] User discovery/enumeration issue due to domain settings
by Christian Lamparter
Hello Folks,
I'm currently setting up sssd (Debian 1.16.3) on Debian Buster 10.0
and I ran into a problem that I was able to trace down to the domain
permission/security settings that placed the users into a special OU
that machine accounts can't read.
First a bit of background:
Currently, there's a way to use winbind + friends in order to join
and auth users on the domain. But due to limitations (unreliable
no home directories, gid/uid mapping issues, etc.), I want to give
sssd a try and I tested this with both of the current Debian sssd
version 1.16.3 and 2.2.0-4 (from unstable / sid / rolling release).
I successfully used the "realm" utility to discover and setup the
sssd.conf
===
# realm discover -v DOMAIN (named changed)
* Resolving: _ldap._tcp.domain
* Performing LDAP DSE lookup on: 1x.y.z.1
* Performing LDAP DSE lookup on: 1z.a.b.c
* Performing LDAP DSE lookup on: 1d.e.f.g
* Successfully discovered: domain
domain
type: kerberos
realm-name: DOMAIN
domain-name: domain
configured: no
server-software: active-directory
client-software: sssd
required-package: sssd-tools
required-package: sssd
required-package: libnss-sss
required-package: libpam-sss
required-package: adcli
required-package: samba-common-bin
# realm join -v -U me@DOMAIN domain
* Resolving: _ldap._tcp.domain
* Performing LDAP DSE lookup on: 1x.y.z.1
* Performing LDAP DSE lookup on: 1z.a.b.c
* Performing LDAP DSE lookup on: 1d.e.f.g
* Successfully discovered: domain
Password for me@DOMAIN: *******
* Unconditionally checking packages
* Resolving required packages
[...]
* Generated 120 character computer password
* Using keytab: FILE:/etc/krb5.keytab
* Found computer account for COMPUTER
* Set computer password
* Retrieved kvno '14' for computer account in directory: ...
* Modifying computer account: userAccountControl
* Modifying computer account: operatingSystemVersion,
operatingSystemServicePack
* Modifying computer account: userPrincipalName
* Cleared old entries from keytab: FILE:/etc/krb5.keytab
* Discovered which keytab salt to use
* Added the entries to the keytab: ...
* /usr/sbin/update-rc.d sssd enable
* /usr/sbin/service sssd restart
* Successfully enrolled machine in realm
===
/etc/sssd/sssd.conf
[sssd]
domains = domain
config_file_version = 2
services = nss, pam, ifp # added ifp
[domain/domain]
ad_domain = domain
krb5_realm = DOMAIN
realmd_tags = manages-system joined-with-adcli
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = True
fallback_homedir = /home/%u@%d
access_provider = ad
===
klist shows a valid ticket and everything seemed to be working.
But when I was trying to login (yes, I made sure that my time is synced
and I made sure /etc/nssswitch.conf was correct) with my "me@domain"
login it never worked. I tried also id me@domain and sssctl (had to add
ifp, seems like realm doesn't add) but it wasn't working for my login.
After trying a lot of different combinations with different id,
auth_providers and ldap I discovered that the AD Server is setup
in such a way (probably due to DSVGO) that the Domain-PC Accounts
are not allowed to read from the OU where all the staff users are
placed. And indeed, when I copied the exact search query from the
sssd_domain log with debug-level 7 and instructed
ldapsearch to use GSSAPI with the Domain-PC ticket I always got a
"not found". However, when I used simple bind with "me@domain" +
password auth I got the request worked.
So, I wonder if it is possible to extend sssd in such a way that
id lookups could be performed with the provided either a provided
user secret instead of the machine secret?
Regards,
Christian
4 years, 8 months
socket activated services and "implicit" sssd.conf?
by Andreas Hasenack
Hi there,
I'm trying to update the sssd package in ubuntu to 2.2.0, and while
the upstream tests pass, and our integration tests pass too, I get
this warning (error?) with the socket services right after
installation:
(https://pastebin.ubuntu.com/p/ZzW8BG2fpm/)
root@eoan-sssd2:~# systemctl status sssd-autofs.service
● sssd-autofs.service - SSSD AutoFS Service responder
Loaded: loaded (/lib/systemd/system/sssd-autofs.service; indirect;
vendor preset: enabled)
Active: inactive (dead)
Docs: man:sssd.conf(5)
root@eoan-sssd2:~# systemctl status sssd-nss.socket
● sssd-nss.socket - SSSD NSS Service responder socket
Loaded: loaded (/lib/systemd/system/sssd-nss.socket; enabled;
vendor preset: enabled)
Active: failed (Result: exit-code) since Thu 2019-08-01 12:49:07
UTC; 16min ago
Docs: man:sssd.conf(5)
Listen: /var/lib/sss/pipes/nss (Stream)
Aug 01 12:49:07 eoan-sssd2 systemd[1]: Starting SSSD NSS Service
responder socket.
Aug 01 12:49:07 eoan-sssd2
sssd_check_socket_activated_responders[3012]: (Thu Aug 1
12:49:07:354960 2019) [sssd] [check_socket_activated_responder]
(0x0020): ini_config_file_open() failed [2][No such file or directory]
Aug 01 12:49:07 eoan-sssd2
sssd_check_socket_activated_responders[3012]: (Thu Aug 1
12:49:07:355071 2019) [sssd] [main] (0x0010): Misconfiguration found
for the nss responder.
Aug 01 12:49:07 eoan-sssd2
sssd_check_socket_activated_responders[3012]: The nss responder has
been configured to be socket-activated but it's still mentioned in the
services' line in /etc/sssd/sssd.conf.
Aug 01 12:49:07 eoan-sssd2
sssd_check_socket_activated_responders[3012]: Please, consider either
adjusting your services' line in /etc/sssd/sssd.conf or disabling the
nss's socket by calling:
Aug 01 12:49:07 eoan-sssd2
sssd_check_socket_activated_responders[3012]: "systemctl disable
sssd-nss.socket"
Aug 01 12:49:07 eoan-sssd2 systemd[1]: sssd-nss.socket: Control
process exited, code=exited, status=2/INVALIDARGUMENT
Aug 01 12:49:07 eoan-sssd2 systemd[1]: sssd-nss.socket: Failed with
result 'exit-code'.
Aug 01 12:49:07 eoan-sssd2 systemd[1]: Failed to listen on SSSD NSS
Service responder socket.
There is no /etc/sssd/sssd.conf file present, so I think it assumes
some defaults. What are these?
After install I get these services running:
1871 ? Ss 0:00 /usr/sbin/sssd -i --logger=files
1872 ? S 0:00 \_ /usr/libexec/sssd/sssd_be --domain
implicit_files --uid 0 --gid 0 --logger=files
1873 ? S 0:00 \_ /usr/libexec/sssd/sssd_nss --uid 0
--gid 0 --logger=files
So here is my assumption: there is an implicit sssd.conf configuration
that is taken in since there is no actual sssd.conf file, and that
just starts sssd_nss, and at the *same* *time* we are trying to use
socket activation, which then says "why are you starting the socket
listener, since you are already starting nss?" I'm guessing only
debian-based systems see this, because we start the services right
after installation, and don't have a default sssd.conf file shipped
with the package.
4 years, 8 months
Re: FAILED with error NT_STATUS_LOGON_FAILURE
by J. Dalton Humpf
I would like to know versions, exact configs, and list of all installed
software or something
I have been trying to fix this for months
--
[image: Image may contain: Dalton Humpf, smiling, beard and closeup]
*J. Dalton Humpf* / Director of Computer Science Laboratories
JHumpf(a)hamilton.edu / (315)859-4452
*Hamilton College*
https://cs.hamilton.edu
198 College Hill Road, Clinton, NY 13323
4 years, 8 months
Re: Could not convert objectSID ... to a UNIX ID
by Gordon Messmer
On Tuesday, July 30, 2019 22:35 PDT, Sumit Bose <sbose(a)redhat.com> wrote:
>
> the version of SSSD you are using should automatically pick a new range
> if the RID is too large. Can you send your sssd.conf for a start to
> better understand your setup and see what might preventing SSSD from
> picking a new range?
The configuration file is generated by "realm join". Are there any
specific patterns you'd like to see from the logs that might provide
more information?
[sssd]
domains = business.com
config_file_version = 2
services = nss, pam
[domain/business.com]
debug = 6
ad_domain = business.com
krb5_realm = BUSINESS.COM
realmd_tags = manages-system joined-with-samba
cache_credentials = False
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = False
fallback_homedir = /home/business/%u
access_provider = ad
4 years, 8 months