On 28/03/2011 11:43, George Mamalakis wrote:
On 24/03/2011 16:28, George Mamalakis wrote:
Hello everybody,
In short:
nsswitch seems not to honor (fully) the criteria and actions of
nsswitch.conf. A detailed analysis of my problem can be found on this
thread (it's on freebsd forums, and it hasn't been answered yet):
http://forums.freebsd.org/showthread.php?t=22716
Thank you all for your time and help in advance,
I hope that somebody will help me realize how nsswitch works, so as
to see if and how caching may help me on an nss_ldap authenticated
configuration,
regards,
mamalos
Anybody having an idea on what might be wrong with the nsswitch
mechanism?
Have I used the wrong mailing list? Should I have used
freebsd-questions instead?
Thank you all for your time in advance.
mamalos
Hmm,
I found two more problems with nsswitch, regarding su(1) this time:
1) If I use SASL authentication in nss_ldap, then when I try to:
$ su -
Password:
#
On /var/log/messages I get the error:
Mar 28 18:17:03 mamalacation su: GSSAPI Error: Miscellaneous failure
(see text) (open(/tmp/krb5cc_1001): No such file or directory^B)
Mar 28 18:17:03 mamalacation su: nss_ldap: could not search LDAP server
- Server is unavailable
which is a bit peculiar, since 1001 is my default user (mamalos), and it
seems that su(1) tries to find a principal with a uid=1001 when it tries
to access nsswitch information, instead of using the sasl_authid user
from /usr/local/etc/nss_ldap.conf.
If I use binddn=blabla, then everything works just fine.
2) When my /etc/nsswitch.conf reads:
hosts: ldap files
group: ldap files
and I run:
$ id mamalos
uid=1001(mamalos) gid=513(Domain Users) groups=513(Domain
Users),512(Domain Admins),0(wheel),814(puppet)
we see that mamalos is a member of the wheel group. But when I try to
su(1) to root I get a "BAD SU mamalos to root" in /var/log/messages.
When my /etc/nsswitch.conf reads:
hosts: files ldap
group: files ldap
and I run:
$ id mamalos
uid=1001(mamalos) gid=1001(mamalos)
groups=1001(mamalos),0(wheel),814(puppet),512(Domain Admins)
then, suing to root works just fine. The same holds when I run id(1)
(with no arguments); in that case, the system replies with the
information it finds in the first resource (ldap on the first example,
file on the second) and stops.
That said, I come into two separate conclusions:
1) SASL authentication in nss_ldap doesn't seem to be fully functional.
2) It seems that some commands call functions that honor the
criteria/actions fields of /etc/nsswitch.conf, while other commands call
functions that don't (like the id and getent).
Any comments on these issues are welcome,
mamalos
--
George Mamalakis
IT Officer
Electrical and Computer Engineer (Aristotle Un. of Thessaloniki),
MSc (Imperial College of London)
Department of Electrical and Computer Engineering
Faculty of Engineering
Aristotle University of Thessaloniki
phone number : +30 (2310) 994379
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[email protected]"
