On 07/ 8/10 11:25 AM, Afshin Salek wrote:
I don't believe enabling guest access is exposed in current 7000 BUI
I don't have any knowledge of if/when it will be available.

I'd recommend that you raise this issue through your support channel.

Agreed.

In response to the discussion below.  svchost.exe is just a program
launcher.  Some Windows services are implemented purely in DLLs,
which can't be execute directly.  svchost.exe is a generic
application that is used to start (launch) such DLL services.

SYSTEM is a local, well-known account, which doesn't have rights
on other systems.  Local OS services are often started using the
local SYSTEM account.

Services that may need to connect to remote servers should have a
means to specify the account used to make that remote connection.
There is typically a panel titled 'Log On' to change the account
used.

Services are located under something like:

  Administrative Tools -> Component Services -> Services (Local)

Under 'Log On', you should find options such as:
        o Local System account
        o This account

Where 'This account' can be a domain account.

If this is not provided for the service you are using, I'd recommend
contacting Microsoft or whoever provides that service to ask how you
can configure it to work across the network.

Alan

Afshin

On 07/ 2/10 10:02 PM, Alex Ball wrote:
Thanks for your response.

I'm curious how to enable guest access, in some documentation I had read
that the OpenSolaris CIFS implementation explicitly does not permit
unauthenticated "guest" access (unlike Linux's samba, etc). I'm aware
that the fishworks interface isn't *exactly* the same as OpenSolaris but
I don't see any options for guest mode. My first intent was to somehow
map all incoming connections to a named user with full permissions on
the share.

I have changed the running user for all services I can ( this case is a
mail system, imap/pop3/smtpd/etc), but the "svchost.exe" process which
runs as "SYSTEM" and afaik cannot be changed gets some calls and ends up
trying to read from the share. Using tools like file monitor I can see
that this process gets some work to do against the share and when it
does permission is denied and the user gets a weird IMAP error. I'd
think all work should be handled by the main service processes, and have
asked the mail software vendor about this but the storage should allow
it.

Interestingly, I ran a packet capture on the active directory servers
while I recreated the problem from the mail server. Normally when I open
the share from my user in explorer the storage server talks with the AD
server to authorize my username, but when the request comes from the
mail server (the local system\system account) the storage server does
not query the AD server about the user. This leads me to believe that
the 7110 CIFS process is trying to use SYSTEM in a local context. Next
I'll run a pcap from the mail server to see whats going on between those
two boxes, but in the mean time I attempted to create a username called
"SYSTEM" but had to set a password so used "SYSTEM" again, and it didn't
seem to work with that.

Do you or anyone else have any documentation on enabling guest access on
this platform, or have any other suggestions?

Thanks,

-Alex

On 7/2/2010 8:31 PM, Alan Wright wrote:
Enable guest access, create a local user account called SYSTEM on
your 7110 or...

Dependent on what purpose those SYSTEM owned processes serve, you
may be able to change them on Windows to run under a domain
account, in which case you don't need to do anything on the 7110.
This is a common solution when using over-the-wire backup/archive
applications.

Alan

On 07/ 1/10 12:43 PM, Alex Ball wrote:
Hello all,

I have a 7110 storage appliance and have successfully integrated it
with
the active directory environment. This allows processes running as
active directory users (such as explorer.exe) to open a cifs share with
the set permissions. My problem is that services, running as the
"SYSTEM" user, cannot. I found this post from earlier:

http://www.mail-archive.com/cifs-discuss@opensolaris.org/msg02248.html

and believe the solution may be similar for me, but I have been unable
to add the "S-1-5-18" user to the permissions list. Basically services
running as the SYSTEM user need access to the share. Does anyone have
any pointers?

Thanks!

-Alex
_______________________________________________
cifs-discuss mailing list
cifs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss

_______________________________________________
cifs-discuss mailing list
cifs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss


_______________________________________________
cifs-discuss mailing list
cifs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
_______________________________________________
cifs-discuss mailing list
cifs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss

_______________________________________________
cifs-discuss mailing list
cifs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss

Reply via email to