Tag Info

New answers tagged

0

You can use sssd with RHEL7 Take a look at this guide: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/pdf/Windows_Integration_Guide/Red_Hat_Enterprise_Linux-7-Windows_Integration_Guide-en-US.pdf (verify that you have it installed first: yum info sssd) sssd.conf: [sssd] domains = mycompany.local services = nss config_file_version ...


0

I have solved the problem by changing the setup of Centos to be more like the set up in Ubuntu. I created the group shadow with a low group id and no members. I changed the group for /etc/shadow and /sbin/unit_chkpwd to the created group shadow. And lastly I made unix_chkpwd SGID: ----r----- 1 root shadow 1049 Aug 22 16:38 /etc/shadow -rwxr-sr-x 1 root ...


0

Not an expert on pam but if you're using access.conf you need a reference to pam_access.so. perhaps: account required pam_access.so Just keep a root shell open while you test. I've managed to lock out the root user with a bad pam edit.


0

Assuming you're using sssd on your hosts, the "filter_users" and "filter_groups" options in sssd.conf appear to address your problem.


1

You need to enable the user to use cron in the login access control table file /etc/security/access.conf Use the following entry which will allow the coins user to run cron jobs: # Allow the coins user to run cron jobs +: coins : cron crond :0 Ensure it is above the last entry: # Deny all other users access by any means. -: ALL : ALL As this entry ...


1

You might check what's in here: /etc/cron.allow and also see if selinux is running and causing the problem. Poking around /var/log/messages or syslog is recommended.


-1

Note that having MaxAuthRetries in sshd >3 probably means you kinda mess up brute-force crack attempts a bit. They are trying 6 different passwords with each ssh connection attempt and think they all failed, but unknown to them one of the last 3 attempts might have actually been correct but was ignored.


2

This worked... but as this basically removes all forms of authentication, DO NOT DO THIS... /etc/pam.d/sshd auth required pam_permit.so Where any other lines which start with auth (aka the module) were commented out... you should also check any @include lines, as they may include files that set further auth modules, e.g. #@include common-auth ...


0

When you run getent passwd, do you see your LDAP users listed? If not, make sure libnss-ldapd is installed, and run dpkg-reconfigure libnss-ldapd and make sure at least the passwd database is enabled (and you'll probably want group and shadow as well, sooner or later). If getent passwd mentions your LDAP users but you can't auth as one, run pam-auth-update ...


1

So, it turned out that Kerberos in combination with low entropy was causing the problem. Since I was not using Kerberos, I ran pam-auth-update and unselected Kerberos.


0

The username that DB2 receives is the pre-Windows 2000 value. In that case, there could be two usernames in ActiveDirectory The first one for normal usage. The other one, for compatibility with other systems, like DB2.


5

My first advice would also be trying strace -f sudo who. But this won't work, since strace will not trace SUID programs. You have to attach to your shell using strace as root and then call sudo. In your shell type $ echo $$ to get your shells PID. Then open another terminal and become root in that terminal. There you type # strace -f -t -T -p $pid -o ...



Top 50 recent answers are included