I read about secsetup, but didn't use it at first!!!!
This solved all the irregularities I was observing.
So apparently using convuser changed things half way,
and running secsetup took care of all.
Everything works perfectly.
Thanks Ann Majesky
*****************
You should be using secsetup to migrate from
Base to Enhanced Security. See the Security
Manual.
Ann
--- Tru64 User <tru64user_at_yahoo.com> wrote:
> Hi,
> I did receive some hints from the following people:
> Darryl Cook, Dr. Thomas Blinn, Bugs Brouillad, Arnie
> Miles and Collin Bull. Many thanks.
>
> My problem is resolved, for now, but not in the
> right
> way. I had to patch it up.
> I concluded problem is not with Samba in this case
> (nothing changed in samba configuration) but with
> Enhanced Security setup.
>
> Updating passwd thru dxaccounts or passwd command
> only
> alters the entry in the /etc/passwd, not the
> protected
> db. Samba is looking into auth.db (protected db)
> entry, to authenticate requests to open up shares on
> Unix from Windows at this site.
>
> When i change passwd on unix box, the unix login
> works fine with the new passwd, but it is not
> updated
> in the protected db. i created a phony passwd
> program
> to replace the original, and it has these two lines
> in
> it:
> /bin/passwd
> convuser -a
>
> In this case, everytime someone updates their
> passwd,
> the protected db is updated too, so opening shares
> with the new passwd works once again.
>
> If you have a clue to the right way of doing this,
> let
> me know. Otherwise I am going thru tru64 security
> manuals online, so far no leads.
>
> Converting back to base security (convuser -b) had
> no
> effect. Samba still looked at the protected db.
>
> There is no $SAMBAHOME/private/smbpasswd file, so
> according to samba info, it should default to
> regular
> passwd file (not sure why it picks auth.db,
> testparm
> shows $SAMBA/private/smbpasswd as passwd file)
>
> _Thanks once again.
>
> Richard
>
>
>
>
>
> --- Tru64 User <tru64user_at_yahoo.com> wrote:
> > Hi,
> > After getting several complains from authck -a
> that
> > some new users are in /etc/passwd but not in
> > protected
> > passwd db,
> > i ran convuser -a, and authck stopped complaining.
> >
> > Problem comes that after running convuser -a, I
> then
> > changed my passwd (user passwd, not root). Now
> when
> > i
> > try to login thru samba, it does not recognize my
> > new
> > passwd, instead, my old one still works.
> > How do i synchronize (or better yet, make sure
> > system
> > synchronizes passwds) to avoid this problem?
> > Before running convuser, changing my passwd on
> unix
> > machine and thenloggin in from nt had no problem
> > recognizing the new one.
> >
> > second part is a diff i see btwn 2 machines, both
> > with
> > enhanced security installed and enabled
> (supposedly,
> > since I ran convuser -a to correct few accounts).
> >
> > One has place holders, (*) in the passwd field in
> > /etc/passwd, while the other has the actual
> > encrypted
> > passwd. Both work, no problems, but curiousity to
> > learn has me wondering why is this so. Checked
> man
> > pages for prpasswd, authck, edauth, convuser,
> still
> > not a clear picture.
> >
> > Note: The system with the place holder (*) does
> not
> > have an /etc/shadow file. Apart from performing
> > strings on /var/tcb/files/auth.db, i dont see
> > anywhere
> > else where passwds are. How else is this enabled?
> > I dont use NIS, and run 4.0g.
> > Please educate
> >
> > _Thanks in advance.
> >
> > Richard
> >
> > =====
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Find a job, post your resume.
> > http://careers.yahoo.com
>
>
> =====
>
>
> __________________________________________________
> Do You Yahoo!?
> Find a job, post your resume.
> http://careers.yahoo.com
=====
__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com
Received on Tue Nov 06 2001 - 19:43:14 NZDT