I was deleting a user.
# userdel u1
The memcache was not invalidated by nss responder.
But finally the user was deleted. What does "The memcache was not invalidated by nss responder" means?
Fedora 34
Thanks
I was deleting a user.
# userdel u1
The memcache was not invalidated by nss responder.
But finally the user was deleted. What does "The memcache was not invalidated by nss responder" means?
Fedora 34
Thanks
I've almost got my AD integration working completely on my OpenSUSE 12.1 server. I have a OpenSUSE 11.4 system successfully integrated into our AD environment. (Meaning, we use LDAP to authenticate to AD directory via Kerberos, so we can login to our *nix systems via AD users, using name service caching daemon to cache our passwords and groups).
Also, important to note these systems are in our LAN, SSL authentication is disabled.
I am almost all the way there. nss_ldap
is finally authenticating with LDAP server (as /var/log/messages
shows), but right now, I have another problem:
getent passwd
and getent shadow
fails (shows local accounts only), but getent group
works! getent group
shows all my ad groups!
I copied over the relavent configuration files from my working OpenSUSE 11.4 box:
/etc/krb5.conf
/etc/nsswitch.conf
/etc/nscd.conf
/etc/samba/smb.conf
/etc/sssd/sssd.conf
/etc/pam.d/common-session-pc
/etc/pam.d/common-account-pc
/etc/pam.d/common-auth-pc
/etc/pam.d/common-password-pc
I didn't modify anything between the two. I really don't think I need to modify anything, because getent passwd, getent shadow, and getent group all works fine on the OpenSUSE11.4 box.
Attempting to restart nscd service unfortunately didn't do much, and niether did running /usr/sbin/nscd -i passwd
.
Do any of you admin-gurus have any suggestions?
Honestly, I'm happy I made it this far. I'm almost there guys!
I am trying to use curl built with NSS (not built with OpenSSL) on Fedora 14 to connect to a webpage over https. The server to which I am connecting (example.com) uses the RC4-SHA cipher for its SSL. Whenever I try to connect to example.com, I get the NSS error SSL_ERROR_NO_CYPHER_OVERLAP
. I can connect via curl on this computer to example-2.com which has the DHE-RSA-AES256-SHA cipher. I can connect to example.com from a different computer that has curl built with OpenSSL.
How do I find out which ciphers are enabled on NSS and how do I enable the RC4-SHA cipher on NSS?
On my Ubuntu 9.10 system, there's a shadow
system group. There does not appear to be any user assigned to this group at all. The only files that I can find belonging to this group are /etc/shadow
and /etc/gshadow
.
I'm aware that the purpose of these files is to store the passwords separately, out of reach from regular users who still might want to access passwd
for other reasons.
But what is the purpose of the shadow
group?
The reason I'm curious about this, is because I'm thinking about configuring nsswitch.conf
to store it elsewhere, and would like to know if anything is actually trying to access the shadow
database using shadow
group credentials.
I use a redundant pair of OpenLDAP servers for PAM auth and directory services via NSS. It's been 100% reliable so far, but nothing runs flawlessly forever.
What steps should I take now so I have a fighting chance of recovering from failure of the LDAP server(s)? In my informal testing, it appears that even already authenticated shells are largely useless as all username/uid lookups hang until the directory server comes back.
So far I've come up with only two things:
Any other suggestions?