You have a few options here:
1. You could provide Linux file access on the back of your enterprise
filer. Filers can speak NFS and Kerberos. Bypassing the windows hassle
altogether. Although, probably not AD, these days.
2. Your Linux joins the AD, then you manage users via AD as you would on
windows/Linux clients. You can cook that up yourself or use some of many
commercial client solutions connecting AD with LDAP, NIS,
3. I cannot recommend homebrew alternatives such as running server stuff to
expose the store inside VM/container on windows. Unless you know what you
are doing, they all bypass security of both Linux as well as windows.
4. Work around the problem designing service providing what you need and
running on windows or using a DB instead of storage.
I many ways, this is probably one of the key reasons why cloud got born -
too many people had too many bad choices - fight this windows monster
forever, give up, or avoid it altogether by building simple stuff outside
this environment.
Just my 2c,
T
On Mon, Apr 9, 2018, 8:34 AM michael wrote:
> Nobody at my company has MSDN access or MSCE training. I'm a Linux
> programmer, not a Windows programmer.
>
> My question is this, in an environment where you have MS-DFS shares and
> can't connect to them from Linux and there is probably Active Directory
> as well, can you instead provide a samba
> share with: a workgroup, a username, and a password? To make this more
> acceptable, let the customer set: the workgroup, the username, the
> password, and the share name. The customer will
> have to figure out how to sync files, but I have no idea how else to
> address this. I'm thinking powershell scripting on the Windows server
> to do an rsync or something similar from the
> MS-DFS share to the Samba share every say two minutes. This company
> cannot wait for a solution from the Samba community that fixes Samba and
> MS-DFS integration. A solution could be
> found today, or five years from now. The company needs to sell product
> yesterday. I'm in a difficult spot because the company is financially
> in trouble.
>
> The company has really awful C/C++ code that uses opencv to auto
> calibrate essentially. Reading the code is totally uninformative. I
> haven't formally studied computer vision. Solving this problem of auto
> calibrate not working is worth more than MS-DFS integration. The code
> has horribly uninformative variable names, it is needlessly threaded,
> and it is totally undocumented. I think we tweaked some constants and
> got reasonable results once, but there's no rhyme or reason to what
> those constants should be.
> ___
> PLUG mailing list
> PLUG@pdxlinux.org
> http://lists.pdxlinux.org/mailman/listinfo/plug
>
___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug
