My environment has a mixture of Solaris 8-10 and RHEL 4-5. These clients are currently authenticating against a Sun One 5.X DS. I have migrated the Sun One DB to my lab 389 DS. Users with a three digit uidNumber are unable to login to Linux systems, however if they connect to a Solaris system it works fine. If I add a fourth digit to their uidNumber they are able access Linux systems just fine. Did I miss a setting somewhere?
Thanks,
Tom
RHEL systems prefer uids > 500. Check /etc/pam.d/system-auth*
Terry Soucy
On Nov 25, 2011, at 12:25 AM, "Tom Tucker" tktucker@gmail.com wrote:
My environment has a mixture of Solaris 8-10 and RHEL 4-5. These clients are currently authenticating against a Sun One 5.X DS. I have migrated the Sun One DB to my lab 389 DS. Users with a three digit uidNumber are unable to login to Linux systems, however if they connect to a Solaris system it works fine. If I add a fourth digit to their uidNumber they are able access Linux systems just fine. Did I miss a setting somewhere?
Thanks,
Tom
389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
On 11/24/11 23:25, Tom Tucker wrote:
My environment has a mixture of Solaris 8-10 and RHEL 4-5. These clients are currently authenticating against a Sun One 5.X DS. I have migrated the Sun One DB to my lab 389 DS. Users with a three digit uidNumber are unable to login to Linux systems, however if they connect to a Solaris system it works fine. If I add a fourth digit to their uidNumber they are able access Linux systems just fine. Did I miss a setting somewhere?
Thanks,
Tom
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
The problem is more likely to be a limitation imposed by the PAM configuration on the Linux systems. Go look at /etc/pam.d/* and look for lines like: account sufficient pam_succeed_if.so uid < 500 quiet A grep for 500 should find lots of examples. The most likely conflict is in /etc/pam.d/system-auth. Comment the line and try again.
Once upon a time UID numbers up through 99 were reserved for the OS, but somewhere along the line we ran out of numbers for such things as Apache, ssh, etc. which each needed their own number. Someone then decided that disallowing logins on these numbers was a good thing. Unfortunately, a lot of places have extant UIDs < 500 (mine is 402).
You have two choices: 1. Change the UIDs of the logins of these users and all their files on all the systems they use. 2. Leave them alone and "fix" every Linux system.
The problem with the second choice is that you could have people with the same UID as system processes. When they do an "ls -l" they may see that their files belong to "smolt" or "nagios" or similar. Also, they would be able to edit files that perhaps should be off limits to them.
Thanks for the feedback.
If I comment out "auth requisite pam_succeed_if.so uid >= 500 quiet" in the system-auth file I was able to login with a UID of 108. Assuming this restrictions is controlled on the Linux system, why do I experience no problems when authenticating against the Sun One DS? I agree, the proper fix would be to change users UID higher than 500.
On Fri, Nov 25, 2011 at 8:08 AM, Gary Algier gaa@ulticom.com wrote:
On 11/24/11 23:25, Tom Tucker wrote:
My environment has a mixture of Solaris 8-10 and RHEL 4-5. These clients are currently authenticating against a Sun One 5.X DS. I have migrated the Sun One DB to my lab 389 DS. Users with a three digit uidNumber are unable to login to Linux systems, however if they connect to a Solaris system it works fine. If I add a fourth digit to their uidNumber they are able access Linux systems just fine. Did I miss a setting somewhere?
Thanks,
Tom
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
The problem is more likely to be a limitation imposed by the PAM configuration on the Linux systems. Go look at /etc/pam.d/* and look for lines like: account sufficient pam_succeed_if.so uid < 500 quiet A grep for 500 should find lots of examples. The most likely conflict is in /etc/pam.d/system-auth. Comment the line and try again.
Once upon a time UID numbers up through 99 were reserved for the OS, but somewhere along the line we ran out of numbers for such things as Apache, ssh, etc. which each needed their own number. Someone then decided that disallowing logins on these numbers was a good thing. Unfortunately, a lot of places have extant UIDs < 500 (mine is 402).
You have two choices: 1. Change the UIDs of the logins of these users and all their files on all the systems they use. 2. Leave them alone and "fix" every Linux system.
The problem with the second choice is that you could have people with the same UID as system processes. When they do an "ls -l" they may see that their files belong to "smolt" or "nagios" or similar. Also, they would be able to edit files that perhaps should be off limits to them.
-- Gary Algier, WB2FWZ gaa at ulticom.com +1 856 787 2758 Ulticom Inc., 1020 Briggs Rd, Mt. Laurel, NJ 08054 Fax:+1 856 866 2033
Nielsen's First Law of Computer Manuals: People don't read documentation voluntarily. -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Hello,
the main reasons ... all account below 500 are system account in Redhat,CentOS.
In ubuntu and Debian all user account below >1000 are system account.
2011/11/25 Tom Tucker tktucker@gmail.com
Thanks for the feedback.
If I comment out "auth requisite pam_succeed_if.so uid >= 500 quiet" in the system-auth file I was able to login with a UID of 108. Assuming this restrictions is controlled on the Linux system, why do I experience no problems when authenticating against the Sun One DS? I agree, the proper fix would be to change users UID higher than 500.
On Fri, Nov 25, 2011 at 8:08 AM, Gary Algier gaa@ulticom.com wrote:
On 11/24/11 23:25, Tom Tucker wrote:
My environment has a mixture of Solaris 8-10 and RHEL 4-5. These clients are currently authenticating against a Sun One 5.X DS. I have migrated the Sun One DB to my lab 389 DS. Users with a three digit uidNumber are unable to login to Linux systems, however if they connect to a Solaris system it works fine. If I add a fourth digit to their uidNumber they are able access Linux systems just fine. Did I miss a setting somewhere?
Thanks,
Tom
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
The problem is more likely to be a limitation imposed by the PAM configuration on the Linux systems. Go look at /etc/pam.d/* and look for lines like: account sufficient pam_succeed_if.so uid < 500 quiet A grep for 500 should find lots of examples. The most likely conflict is in /etc/pam.d/system-auth. Comment the line and try again.
Once upon a time UID numbers up through 99 were reserved for the OS, but somewhere along the line we ran out of numbers for such things as Apache, ssh, etc. which each needed their own number. Someone then decided that disallowing logins on these numbers was a good thing. Unfortunately, a lot of places have extant UIDs < 500 (mine is 402).
You have two choices: 1. Change the UIDs of the logins of these users and all their files on all the systems they use. 2. Leave them alone and "fix" every Linux system.
The problem with the second choice is that you could have people with the same UID as system processes. When they do an "ls -l" they may see that their files belong to "smolt" or "nagios" or similar. Also, they would be able to edit files that perhaps should be off limits to them.
-- Gary Algier, WB2FWZ gaa at ulticom.com +1 856 787 2758 Ulticom Inc., 1020 Briggs Rd, Mt. Laurel, NJ 08054 Fax:+1 856 866 2033
Nielsen's First Law of Computer Manuals: People don't read documentation voluntarily. -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
389-users@lists.fedoraproject.org