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 at 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 at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-directory-users
