Well, I've gotten the phantom group error message again.

groups: cannot find name for group ID 1596003650

So, I tried to get some info:
root@snickers:~# getent group -s sss 1596003650
root@snickers:~# 
As you can see, no output from getent.

So, I did an AD query as outlined here: http://blog.schertz.name/2008/03/searching-ad-for-a-user-account-with-a-sid/ This is the query I performed:
(&(objectCategory=*)(objectSID=\01\05\00\00\00\00\00\05\15\00\00\00\D9\4D\0B\6A\B4\D6\05\0E\16\51\0D\E2\42\0E\00\00)) 

No results found. So, the group reported REALLY doesn't exist, contrary to what we found earlier. I've got sanitized, detailed logs:
Bear in mind, I had to do some regex to remove sensitive information like usernames and full names.

-Chris


On Fri, Aug 23, 2013 at 11:20 AM, Stephen Gallagher <sgallagh@redhat.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/23/2013 11:09 AM, Chris Hartman wrote:
>
> On Fri, Aug 23, 2013 at 8:29 AM, Jakub Hrozek <jhrozek@redhat.com
> <mailto:jhrozek@redhat.com>> wrote:
>
> Do you run AD server in a trusted setup? Is it possible this group
> comes from another AD domain?
>
> No. We have a single domain. No trusts or subdomains.
>
> Can you check if searching the SID in the Global Catalog works
> (just search port 3268)? # ldapsearch -H
> ldap://milkdud.TESTDOMAIN.local:3268 -Y GSSAPI -N -b
> "dc=testdomain,dc=local" \
> "(&(objectSID=S-1-5-21-1779125721-235263668-3792523542-3663)(objectclass=group)(name=*))"
>
>  Here are the results of that query:
>
> USER@HOST:~$ ldapsearch -H ldap://milkdud.TESTDOMAIN.local:3268 -Y
> GSSAPI -N -b "dc=testdomain,dc=local"
> "(&(objectSID=S-1-5-21-1779125721-235263668-3792523542-3663)(objectclass=group)(name=*))"SASL/GSSAPI
>
>
authentication started
> SASL username: USER@TESTDOMAIN.LOCAL SASL SSF: 56 SASL data
> security layer installed. # extended LDIF # # LDAPv3 # base
> <dc=wysu,dc=local> with scope subtree # filter:
> (&(objectSID=S-1-5-21-1779125721-235263668-3792523542-3663)(objectclass=group)(name=*))
>
>
# requesting: ALL
> # # search result search: 4 result: 0 Success # numResponses: 1
>
>
> Also, I've actually not seen the original error in a few days and
> have failed to reproduce it the few times I tried just now, so
> perhaps this was a fluke? The only thing that has happened since
> then has been a reboot or two of each domain controller. No changes
> to AD or any of the SIDs in question. I'd be okay with shelving
> this issue until it rears its head again. If any curious party
> wants me to experiment some more, I'd be happy to oblige, I'll just
> need some direction because I'm stumped. Otherwise, I'll monitor
> the issue for a few more days and post back with one more follow up
> if I can't reproduce it.
>

My best guess here is that you might have had an entry with that SID
on one replica that wasn't syncing properly. Every once in a while,
SSSD would end up connected to that replica at login.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlIXfbEACgkQeiVVYja6o6PtiQCeOWxrq3Dmbbuo7hT7YHNrUjNr
NaMAn3AVnDB0qaI5iFUbZN+Qg6JDlwdf
=0K5v
-----END PGP SIGNATURE-----
_______________________________________________
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users