SAMBA again

[Roger Oberholtzer]

On Wed, 2005-11-16 at 11:20 +0800, Chong Yu Meng wrote:
> Hi Roger,
> 
> See my comments in-line below:
> 
> Roger Oberholtzer wrote:
> 
> >I have been trying to get a Windows Primary Domain Controller (PDC) to
> >validate users for my Linux SAMBA. I seem on the verge of getting it to
> >work. I have one question I don't see a proper answer for:
> >
> >When I join a domain, the docs say to log in as 'administrator'. Is this
> >a requirement that you be administrator on the PDC, or just sloppy
> >documentation? 
> >
> AFAIK, the first time you login to the domain, you WILL need to be 
> administrator, whether you are joining a Linux or a Windows box to the 
> domain. What I mean by that is: your PDC may have one or several 
> administrator accounts-- you will need to use the userID and password 
> from one of those administrator accounts to join the domain, the first 
> time! The reason for that seems to be that the first time you login to a 
> domain, it downloads authentication information, such as domain user 
> names and group names to your domain member. If you are NOT 
> administrator, I do not think that you can query the authentication 
> database.
> 
> >There is no way in hell your average admin is going to
> >give out administrator accounts/passwords to linux boxes scattered
> >around the net
> >
> Actually, you could tell the administrator that you are joining a 
> Windows box and need an administrator account's credentials. That 
> normally works for me! ;) Windows boxes still need the administrator 
> credentials to join the domain, for the FIRST TIME only. Linux boxes may 
> be different (see below)

FIRST TIME relative to what? Booting? Linux installation? Starting
winbind? If something is downloaded, where is it being kept? Which part
of the whole chain in Linux is responsible for keeping this one-time
information so I do not loose it buy some seemingly innocent activity?

> >Where in SAMBA/winbind do you configure the name/password of the user
> >you should use to join the domain? 
> >
> >  
> >
> You do not configure the name and password. Instead the process of 
> joining a domain, again AFAICT, is to run this on the command line,
> 
> # net rpc join -W <domain_name> -U <domain_user_account>

Perhaps not on SUSE. I think (details are scarce on the ground). I
'think' you need an account that is the name of your machine. I have
made all the additions described elsewhere in this thread. I have made
the Kerberos entry as well, even though there is a claim that as I am
only passing things to the ADS controller and not actually acting as a
controller, this is not needed.

For example, I see things like this in the samba logs:

libads/sasl.c:ads_sasl_spnego_bind(215)  ads_sasl_spnego_bind: got
server principal name =sto-dc-3$@SCC.SE

libsmb/clikrb5.c:ads_krb5_mk_req(384)  ads_krb5_mk_req:
krb5_cc_get_principal failed (No credentials cache found)

libads/kerberos.c:ads_kinit_password(146) kerberos_kinit_password
host/STO-OPQ-SRC at SCC.SE failed: Client not found in Kerberos database

printing/nt_printing.c:check_published_printers(3208)
  ads_connect failed: Client not found in Kerberos database


In this setup, sto-dc-3$@SCC.SE is the domain controller. I have neen
told it is sto-dc-3 at SCC.SE, so I am curious where the $ comes from. I
have assumed some windows madness is at play. My machine is
STO-OPQ-SRC at SCC.SE, and there is a account for STO-OPQ-SRC in our
domain. But as this is being performed automatically, what password was
used then it was determined that 'Client not found...'?



> 
> On some domains, you need to be admnistrator to join, because of some 
> login scripts that need to run, etc.

No one is logging in. In fact, they are already logged in to the network
before my SAMBA ever sees them. I just want to authenticate them when
giving them access to my local shares. AFTER they are verified as users,
I would imagine that various local login scripts could be run. Like
making a local Linux account for them. But all these are, I would think,
not part of simple user authentication. They are things I could choose
to do AFTER they access is authenticated Or?


> >Talk about an area with bad documentation. There is lots of it. But it
> >is mostly bad. I have read so much, and it does not always help. The
> >suggested By-Example book does not, that I could identify as such, give
> >a step-by-step COMPLETE guide to joining a domain to authenticate users.
> >You always get one bit here, a disconnected bit there, and so on.
> >
> >  
> >
> That's why it took me 3 years to reach the stage of a Step-by-Step. And 
> even then, there are some things I still do not understand.

I understand the problem. I think it is because all examples try to do
too many things at the same time. In the by-example book, for instance,
it is just an unending series of the IT department needing to do one
isolated thing after another. No single task is taken, as a single
simple task, all the way from start to finish.

How many people must simply want to authenticate a user? Just that
single task. Nothing more or less.


> 
> Hope this helps!

Any and all encouragement is greatly appreciated. I know that all this
stems from my obvious lack of understanding of Windows2000 server user
authentication. To be honest, I do not mind. But I see that this
ignorance is causing me problems on Linux. 


-- 
Roger Oberholtzer
OPQ Systems AB