Well, I'm running nscd, but before I go shutting that off, I should share this
new info:
I found that the solaris machine *does* try to bind as the user, and the
server returns err=53, just like it does to the linux clients! However, it
*then* does a search for the shadowaccount objectclass and the inactive
user's uid, and memberUID=<inactive user>, and in the end, it lets the user
in.
Baffling. And scary that a failed bind request can potentially lead to users
getting logged in anyway.
On Tuesday 30 August 2005 4:24 pm, aly.dharshi(a)telus.net wrote:
Hi Brian,
Is the nscd caching the query ? I guess try restarting nscd and
see if that fixes your problem, if you aren't running nscd this is a
useless suggession.
Cheers,
Aly.
On Tue, 30 Aug 2005, Brian K. Jones wrote:
> Hi all,
>
> I'm running FDS (binary rpm) on rhel4. I have rhel4 and solaris 10
> clients.
>
> If I inactivate a user account in the FDS admin GUI, then try to log in
> via ssh as that inactivated user on any ol' random Linux client, the BIND
> operation fails with err=53 (unwilling to perform). This, I should think,
> is the expected behaviour.
>
> Solaris 10, on the other hand, lets the user in (again, ssh). The only
> BIND I can correllate in the logs come from the solaris proxy user. Then
> a search is done for "shadowaccount=<username>", and then a search
is
> done for the group memberships of that user (presumably I'm already in
> when this is done). There's never a BIND operation as the inactive user
> at all!
>
> Can someone explain what's happening?
>
> brian.
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users(a)redhat.com
>
https://www.redhat.com/mailman/listinfo/fedora-directory-users