Help
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.
Page 1 of 1
Windows XP c$ admin share and SAMBA
#3
Four and Twenty 
- Pooh-Bah
- Group: Members
- Posts: 1623
- Joined: 25-March 00
Posted 20 July 2001 - 09:59 AM
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
#4
Reidyn
- journeyman
- Group: Members
- Posts: 71
- Joined: 19-March 00
Posted 20 July 2001 - 04:03 PM
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!
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!
#6
clutch
- Carpal Tunnel
-
- Group: Moderators
- Posts: 3859
- Joined: 29-March 00
Posted 23 July 2001 - 12:40 AM
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.
#8
Reidyn
- journeyman
- Group: Members
- Posts: 71
- Joined: 19-March 00
Posted 23 July 2001 - 05:24 AM
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.
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.
#9
Reidyn
- journeyman
- Group: Members
- Posts: 71
- Joined: 19-March 00
Posted 01 August 2001 - 06:33 AM
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.
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.
#10
MBlaster
- stranger
- Group: Members
- Posts: 3
- Joined: 03-August 01
Posted 03 August 2001 - 08:28 AM
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.
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.
#11
Reidyn
- journeyman
- Group: Members
- Posts: 71
- Joined: 19-March 00
Posted 16 August 2001 - 01:45 AM
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.
"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.
Share this topic:
Page 1 of 1