Cooper's questions

A while back we started authenticating users on our Linux servers against Active Directory. As far as the actual authentication part goes, things are working great.

However, one of the side effects is that Linux thinks (sort of correctly) that it has several thousands (~15-20k) of users. We've seen several issues that seem to be SELinux related (one of which is https://serverfault.com/questions/236419/usr-bin-install-hangs-apparently-due-to-selinux). Some other issues include:

• dmesg repeatedly reports that restorcon gets killed by oom-killer
• booting on some servers take a very long time - this happens after kernel load, apparently during while reading the volume groups, but also while running the restorecon startup script.
• yum updates hang (similar behavior to my SELinux/GNU 'install' question regarding the mmap/munmap)

We see these issues with SELinux in permissive mode. They go away when we disable SELinux completely. Disabling SELinux is an option. I'm also looking at ways to limit the number of users AD presents to Linux using an OU or group. But nerd in me always wants to know more.

So this is a pretty broad question - but anyone have any advice for dealing with SELinux with a large number of users? I'm not particularly familiar with SELinux - but this could be the learning opportunity.

Is there a way to add a new App Path (for adding commands to Start-Run) without needing Admin?

With admin, you can add an App Path to HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths. I tried adding one under HKCU with no effect.

I've added a new (user-writable) location to my user's PATH environment variable which lets me launch things from Start->Run, but the nerd in me still wants to know about the App Paths.

I have set up an OpenLDAP server on RHEL 5.4, and am configuring other servers to authenticate against it. I have both ldap with StartTLS and ldaps configured and working.

On my client machines, my /etc/nsswitch.conf includes:

passwd:     files ldap
shadow:     files ldap
group:      files ldap

I can successfully log in to a client with a user that is only defined in LDAP (i.e. its not finding it in /etc/passwd, and is successfully asking LDAP for user info, and authenticating against the password hash stored in LDAP).

My problem is when I try to lock down access to attributes in the LDAP server, specifically, in /etc/openldap/slapd.conf, ldap users can no longer log in:

access to attrs=userpassword
        by self write
        by anonymous auth
        by * none

I'm logging slapd, and it appears (my interpretation, correct me if I'm wrong) that pam_ldap is attempting to read all the attributes in the poxixAccount objectClass:

    filter: (&(objectClass=posixAccount)(uid=cthompson))
    attrs:
  uid
  userPassword
  uidNumber
  gidNumber
  cn
  homeDirectory
  loginShell
  gecos
  description
  objectClass

In my openldap logging, I get no access or acl errors, but I do get:

access_allowed: search access to "uid=cthompson,ou=People,dc=domain,dc=com" "objectClass" requested
access_allowed: search access to "uid=cthompson,ou=People,dc=domain,dc=com" "uid" requested

Is there something that needs to be configured so instead of reading the userPassword attribute, pam_ldap tries to "auth" against it (so the requests gets handled by the "by anonymous auth" access rule?

I'm looking for an FTPS (explicit FTP over SSL) UNIX client.

I've checked out several, including those from this list on Wikipedia. Some of my favorites are lftp and cURL, however both are foreign source.

Does the serverfault community have any recommendations for U.S. developed FTPS clients, either open source or commercial? I'm primarily looking for any good clients that are not on that list, however I didn't exhaustively check out everything Wikipedia listed.

edit: Preference for command-line interface. A GUI client might be used as a last resort.

edit: Many of you share exactly my opinion of the "no foreign source" policy. It is completely retarded - I've brought up both Linux and PHP as examples of foreign source software that are used widely in our enterprise. It does frighten me that our security organization is so clueless, but never-the-less, we have been asked to look at U.S. developed options.