Windows XP c$ admin share and SAMBA

[Reidyn 0]

I have a Red Hat 7.1 server, with SAMBA upgraded to 2.2.1a. I have a script with an SMBMOUNT from RedHat to my older 2000 Pro installation's C$ and D$ shares (to read/write certain files on demand). Since installing (clean, reformatted) XP, I can't seem to get authorization for the C$ and D$ shares, using the exact same user ID and password configuration as before. The exact error as reported by SMBMOUNT is something like "Not Authorized"

 

I have already gone through the Network Configuration Wizard, and then manually shared a few folders just to see whether THAT Worked, and it did indeed... I was able to SMBMOUNT and browse those, or SMBCLIENT and browse them. It just doesn't like those hidden administrative shares. I have no idea whether this is due to a change in the means of securing the C$ admin share, or something else that has broken the connectivity with SAMBA. I can already see that XP's security isn't identical to 2000. If anyone knows what I've missed regarding changes in XP's security model, please let me know. Thanks!!!

 

Addendum... Connecting with XP to resources (directories and printers) shared by SAMBA does work.

 

Addendum 2... I'm NOT running the "reset" crack. This copy is activated.

[clutch 1]

Is it using the proper domain designation? Just something I thought I would throw out there. Since the manual selections worked, I didn't know if you script might be missing something.

[Four and Twenty 0]

go to the local area connection properties on the xp box and go to the authentication tab and uncheck "use authentication control IEEE 802" or some sh!t like that

[Reidyn 0]

Thank you both for your replies... Sorry so long for the delay in my own follow-up... my exams this week have preoccupied me.

 

Clutch:

-------

The exact "mount" that I'm using is as follows:

 

mount -w -t smbfs -o username=ccjones,password=<<censored>>,dmask=0744,fmask=0744,workgroup=OLYMPUS //cthulu/d$ /data/cthulu-d

 

Where the workstation that the server is trying to mount, obviously, is "cthulu", and the workgroup (no domain controller exists, only a workgroup designation) is "OLYMPUS". I get the error:

 

6792: tree connect failed: ERRDOS - ERRnoaccess (Access denied.)

SMB connection failed

 

However... if I explicitly share the d: volume on the workstation as "drive-d" and substitute "//cthulu/drive-d" for the "//cthulu/d$", it actually works. On the XP workstation, I can look in Computer Management console and see the existence of the d$ share, and even connect to it locally (as if going through the network) by typing "\\cthulu\d$" as the address in an explorer window. Bizarre. The explicit share will work, but I would prefer to use the hidden administrative share if at all possible (as I did with Win2000).

 

If nothing else, it is cool being able to SSH into my server from work and obtain these details

 

Four and Twenty:

----------------

I'm going to try changing that property as soon as I get home. Thanks for the suggestion!

[Reidyn 0]

No luck with the "IEEE 802.1" option... Disabled it, and still got the "Not Authorized" error... Damn.

[clutch 1]

You can connect via script to another share correct? Then try making another hidden share using the "$" (like reidyn$) and see if you scripting contiues to have errors. It could perceive the "$" as either an illegal character for sharing, or as another command and/or variable.

[CUViper 0]

I think clutch is on the right track..... I wonder, can you escape the '$'? i.e., enter the path as "//cthulu/d\$".... something to try anyway

[Reidyn 0]

It continues to be interesting. I created an invisible share (an entire drive, actually) by appending the "$" after the share (e.g., "reidyn$"), and successfully connected to that share with the expected rights on the Linux server.

 

I also tried "escaping" the "$" in "C$" by substituting a "\$" for the "$".... no luck connecting to the administrative share.

 

Also, for S&G, tried both uppercase and lowercase on the "C$" just in case it had become a case-sensitivity issue with Linux... no luck.

 

I have noticed that in Windows XP, UNLIKE Windows 2000 and NT, explicitly sharing any resource causes a lengthy attribute change of some sort (which I haven't identified WHAT exactly), rather than just quickly creating the share as in earlier OSes. The higher the level being shared (i.e., the more files and folders beneath), the longer it takes. Don't know whether this has a connection... It would be interesting to try to connect to the Windows XP C$ share from a Windows 2000 or NT machine to see whether they can do it, or whether the fact that I can connect back to my own machine from the same machine is because XP is uniquely equipped for whatever changes have taken place.

 

To p!ss me off even more, I can't even get a good search on Google or Deja... the "$" is dropped from the search criteria, and I can't figure a way to retain it.

[Reidyn 0]

It gets more interesting yet....

 

Playing with SMBCLIENT and observing the connection with Computer Management on XP, I can see that even when I log in from SAMBA with the same ID that has admin priveledge on the XP box, it still connects as a separate ID (since the server is the machine that is connecting) and also shows as "guest".

 

If I remove the "everyone" share, and only add my actual ID to have sharing priveledges, then I can't get access from SAMBA even though I'm connecting with that same ID... So unlike 2000 and NT, which would both assume that if you use the same ID you're trying to log in under the same account, this one actually assumes that the same ID on a different box is NOT the same as the local. Now I can't figure how to force it to use the same.

 

Interesting change of authentication. I have tried sending the ID as "xpboxname/username", and "xpboxname\\username" ... no luck. Tried forcing the netBIOS name to be the same as the XP box name, and still can't fool it. Damn it.

 

The temporary solution, I suppose, is to add "\\sambaservername\username" to my XP box's user accounts. I hate that, as I still don't get the C$ and D$ admin shares.

 

There HAS to be an answer. I can't quite figure whether this indicates that SAMBA needs to catch up, or a setting in XP.

[MBlaster 0]

I had the same problem trying to access the admin share even though I

had a local account.

 

Here is what has to be changed:

 

I figured out how to share with login/admin rights as well as remove the <ctrl>

right click junk to bring up the share option...

 

What you need to do is:

1- bring up the local security policy (in admin tools)

2- under security settings -> Local policies -> Security options look for and

change:

a- "do not allow anonymous enumeraation of SAM accounts" it should be Disabled

b- "do not allow anonymous enumeraation of SAM accounts and shares" it should

be Disabled.

c- "force network logons using local accounts to authenticate as Guest" should

be disabled.

[Reidyn 0]

Sorry it took so long... I've been away. This worked BEAUTIFULLY. The only change is that in the local security policy, the #4 item to change has been renamed in RC-2 as:

 

"Sharing and security model for local accounts", which should be changed to "Classic - Local users authenticate as themselves"

 

EXCELLENT work in finding this. I have successfully mounted my administrative shares to my Linux server and deleted the dangerous "everyone" invisible shares.