[Fedora-directory-users] solaris 10 caching credentials? Inactivated users allowed in via ssh

[Brian K. Jones]

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.

[Aly Dharshi]

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
>  
-- 
Aly S.P Dharshi
aly.dharshi(a)telus.net

 	 "A good speech is like a good dress
 	  that's short enough to be interesting
 	  and long enough to cover the subject"

[Brian K. Jones]

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

[Brian K. Jones]

Anyone experiencing a similar issue should see this Sun forum thread
http://forum.sun.com/thread.jspa?threadID=24568&tstart=0

On Tuesday 30 August 2005 4:42 pm, Brian K. Jones wrote:
>  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
>
>  --
>  Fedora-directory-users mailing list
>  Fedora-directory-users(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-directory-users

[George Holbert]

Brian,
It sounds like you're using the pam_unix module for authentication on 
the Solaris 10 client instead of the pam_ldap module.  The bind as the 
proxy user is to retrieve the crypted password hash of the account, 
which is then compared with the password given at login.

If you want LDAP account deactivation to affect logins to Solaris 
clients, those clients must use pam_ldap to authenticate against the 
LDAP server, instead of pam_unix.

Note also that deactivating a LDAP account will not prevent 
password-less rsh login with that account.

-- George


Brian K. Jones wrote:

> Anyone experiencing a similar issue should see this Sun forum thread
> http://forum.sun.com/thread.jspa?threadID=24568&tstart=0
>
> On Tuesday 30 August 2005 4:42 pm, Brian K. Jones wrote:
>   
>
> >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
> &gt;&gt;&gt;Fedora-directory-users(a)redhat.com
> >>>https://www.redhat.com/mailman/listinfo/fedora-directory-users
> >>>        
> >>>
> >--
> >Fedora-directory-users mailing list
> &gt;Fedora-directory-users(a)redhat.com
> >https://www.redhat.com/mailman/listinfo/fedora-directory-users
> >    
> >
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users(a)redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
>   
>

[Brian Jones]

Well, this makes sense, but I'm using the Sun-recommended pam_ldap 
configuration, straight from their documentation for Solaris 10. I don't 
have a machine in front of me, but if memory serves, their configuration 
includes pam_unix_auth, pam_unix_cred as well as pam_ldap. I've read about 
the changes with server_policy and the like, but even those example (again, 
iirc) use pam_unix. 

If you have a working pam.conf for solaris 10 that doesn't exhibit this 
behavior, I'd be happy not so much to see it, but to know what doc you 
referenced to develop it! 

Thanks, 
brian

On 8/30/05, George Holbert <gholbert(a)broadcom.com&gt; wrote:
>  
>  Brian,
>  It sounds like you're using the pam_unix module for authentication on
>  the Solaris 10 client instead of the pam_ldap module. The bind as the
>  proxy user is to retrieve the crypted password hash of the account,
>  which is then compared with the password given at login.
>  
>  If you want LDAP account deactivation to affect logins to Solaris
>  clients, those clients must use pam_ldap to authenticate against the
>  LDAP server, instead of pam_unix.
>  
>  Note also that deactivating a LDAP account will not prevent
>  password-less rsh login with that account.
>  
>  -- George
>  
>  
>  Brian K. Jones wrote:
>  
>  >Anyone experiencing a similar issue should see this Sun forum thread
>  >http://forum.sun.com/thread.jspa?threadID=24568&tstart=0
>  >
>  >On Tuesday 30 August 2005 4:42 pm, Brian K. Jones wrote:
>  >
>  >
>  >>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
>  &gt;&gt;&gt;&gt;Fedora-directory-users(a)redhat.com
>  >>>>https://www.redhat.com/mailman/listinfo/fedora-directory-users
>  >>>>
>  >>>>
>  >>--
>  >>Fedora-directory-users mailing list
>  &gt;&gt;Fedora-directory-users(a)redhat.com
>  >>https://www.redhat.com/mailman/listinfo/fedora-directory-users
>  >>
>  >>
>  >
>  >--
>  >Fedora-directory-users mailing list
>  &gt;Fedora-directory-users(a)redhat.com
>  >https://www.redhat.com/mailman/listinfo/fedora-directory-users
>  >
>  >
>  >
>  
>  
>  
>  --
>  Fedora-directory-users mailing list
>  Fedora-directory-users(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-directory-users
>