Anonymous_User Absent Member.
Absent Member.
1638 views

UIDs and GIDs ....

For various reasons, we have chosen to move from using PAM/LDAP to local accounts on some machines. However, to be ready for a possible move back to a PAM/LDAP environment, we would like to keep the UIDs and GIDs matched to what we have in our eDir environment. The problem is, the UIDs and GIDs in our eDir environment come from our central campus IT group and they exceed the number 60000.

Does anyone know of a means to get SLES9 and OES to accept UIDs and GIDs greater then 60000?

Todd R. Strauch
Systems Programmer III
University of Michigan
Ann Arbor, Michigan


Labels (2)
0 Likes
3 Replies
Anonymous_User Absent Member.
Absent Member.

Re: UIDs and GIDs ....

Todd Strauch wrote:
> Does anyone know of a means to get SLES9 and OES to accept UIDs and GIDs greater then 60000?



SLES9/OES should accept them up to 65535, which is the highest they go
due to the size of the integer. This shouldn't be a problem, are you
experiencing one?

--
Justin Grote
Network Architect
JWG Networks
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: UIDs and GIDs ....

No, not really. Our central campus IT group is generating UIDs and GIDs far greater then 65000. As an organization with well over 100000 individuals, they have too. Our identity management tree for the hospital, stores this information. For various security reasons, many of our SLES9 servers are not using PAM/LDAP. Until the issues we have are ironed out, we are going to local accounts. We are trying to keep our local UIDs and GIDs in sync with what is stored in our identity management tree, hence the need/desire to exceed 65000 limit.

Todd R. Strauch
Systems Programmer III
University of Michigan
Ann Arbor, Michigan


0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: UIDs and GIDs ....

Todd Strauch wrote:
> No, not really. Our central campus IT group is generating UIDs and GIDs far greater then 65000.


Then these aren't Unix UIDs and GIDs, but some other form of ID, because
Linux UID's and GID's cannot exceed 655356, because the filesystems and
kernel only use a 16 bit integer to store the UID. You'd have to patch
the kernel and *every* program that uses a UID to support more than 65k
users on a single machine.

Novell's LUM gets around this by allowing multiple unix profiles, each
with different counters, so you can have UIDs for different sets of
people, so you can distribute the 65k among multiple servers.

You really only need to enable LUM for a user if that user needs shell
access to the server, and if you need 100k people with shell access to a
*single* server, you need to rethink your policies.

What kind of Directory are you running that is generating these UIDs and
GIDs? eDirectory or something else?

Why is it so critical to keep the UNIX UID and the directory UID the same?

Do you really need all 100k people to have shell access to a single
server and be visible as LUM users? NSS doesn't require Unix UIDs,
neither does Apache or any other LDAP-enabled application that doesn't
write files with the UID of the connecting user.

Shell access should only be provided for administrative and other users
who need specific filesystem-based access (like Samba). Control this
further by using pam_access to restrict very specific users and very
specific IP addresses to services like SSH, sudo, and su, and you'll
have a secure environment using PAM and NAM/LDAP.

--
Justin Grote
Network Architect
JWG Networks
Email: jgrote@jwgnetworks.com
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.