Re: Authentication problems

Hi Costas,

I think they're aware now of the domain trust issues (they weren't prior to
purchasing SBS), but they feel it's not a problem. It's not a question of
them wanting a separate domain either, it's more a case of "SBS was the
cheapest option so we ordered it".

As much as I'd like to not lose sleep over it, their IT guy (who I suspect
was the one that ordered SBS and is now pulling a CYA move) is hinting that
it's our fault for being inflexible, and our app should have always
supported SQL Auth to begin with, and that we should modify it under the
terms of the maintenance contract (rather than as extra, chargeable work).
Unfortunately he's there all the time, we're only there upon request, so
they hear his side of the story all of the time. We've tried pointing out
that rewriting for SQL Auth would be a retrograde step, and that MS actively
discourages using it, and they do at least seem to have taken that on board.

We have mentioned the EULA, but we've not said outright that they're in
violation, only that we're concerned that they may be (more a sort of "We're
concerned for you" thing). Their IT bod instantly retorted with "No, no
we're not, everything's fine, we've checked, it's all okay" which got me a
bit suspicious. My understanding is that MS prevent users from using SBS
this way because it's designed for small businesses with lower financial
resources. If it worked as a departmental server, then everyone would buy
it, its price would have to rise accordingly, and then the smaller
businesses wouldn't be able to afford it - so it's like stealing from the
little guys.

If they really are in violation of the EULA, then that would actually solve
a lot of problems because the accounts director would instantly just order
up the right version of Windows and get Mr IT to install it. I suspect (but
have not implicated) IT Guy was responsible for the bad decision of
purchasing SBS, but he's quite an expert at passing the buck and thus would
probably blame the hardware supplier for the decision, so it wouldn't create
internal friction.

The issue I have is that we're steadily becoming the "bad guys" for not
being flexible enough to rewrite the software suite, which I find rather
unfair...

-Alex


"Costas" <cpstechgroup@xxxxxxxxx> wrote in message
news:OmaZ1FP5IHA.3768@xxxxxxxxxxxxxxxxxxxxxxx
I think the big question is, do they want to have a separate domain at the
Accounts department and if yes, what is the purpose for it. If they don't
want to discuss it, they need to understand that the SBS domain does not
support domain trusts and if they want you to re-write the app to use SQL
authentication, they will pay for it.

Don't lose sleep over it. If someone is paying for a custom SQL
application, they need to understand they need to carry the costs for
maintaining/modifying it. If I was you, I would stay with the technicals
and wouldn't take the the EULA violation route. I think, if you tell
them they could be in violation of the EULA (I don't say that they are)
you could create friction in the business relationship.

My $0.02

--
Costas
http://costas.cpstechgroup.com




"Alex Clark" <quanta@xxxxxxxxxxxxxxx> wrote in message
news:OeimBD94IHA.1420@xxxxxxxxxxxxxxxxxxxxxxx
Hi all,

I would really appreciate any help that anyone can offer on this, as it's
becoming a major problem for me.

My company wrote an accounting client/server solution with an MS SQL
Server backend for one of our customers, and it worked fine for many
years. Recently however, they just upgraded their hardware across the
entire organisation, including the accounts dept's server and
workstations.

This should have been fine, but they rather foolishly installed SBS2003
onto the accounts dept server. Because of this, the accounts server has
to manage its own domain (ACCOUNTS) whereas all the users on the
workstations in the accounts department still log onto the "master"
domain (ITSERVICES).

This has created authentication problems, because now those users aren't
authenticated against the SBS machine and so cannot connect to the SQL
Server. We told them they need to put Windows Server 2003 Standard on
it, but they refuse. They asked us to rewrite the entire suite of
software to use SQL Authentication instead of Windows Authentication, but
the cost to them would be prohibitive (we're talking about a lot of apps,
and a lot of testing time).

I have tried creating a user account on that SBS box which has database
access, and then running a "net use \\accountsrver\ipc$
/user:ACCOUNTS\accuser password" command at startup for all users.
Although this gives them access to network shares via Windows Explorer,
it doesn't give them access to SQL (I think Explorer does some magic that
SQL via ODBC doesn't or cannot do).

Their current workaround is to create users on the ACCOUNTS domain that
match user accounts in the ITSERVICES domain (exact same user/pass), and
they then automatically get authenticated, but it comes at a price:
1) It's slow
2) Their passwords expire every 6 weeks, meaning they have to be changed
on the accounts server every 6 weeks to sync up to whatever the user's
new password is.

Question 1) Can anyone think of a better workaround than this?


Their IT dept is being rather inflexible and demanding that we rewrite
the software to cover their mistake. We feel they should put the correct
version of Windows on there. I think they have another problem though,
regarding licensing.

Question 2) Are they in violation of the license agreement with MS by
using SBS like this?

The EULA is a bit vague. It does clearly state "You may not use SBS as a
departmental server" and various other things, but it doesn't actually
state "You're violating your license agreement with MS if you do". I
feel they're in a very precarious state license wise, but again their IT
dept. is adamant that there's no violation and that this is a perfectly
acceptable cost-cutting measure, so long as we rewrite our software to
accommodate it.

Sorry for the long post ladies & gentleman, but it required a bit of
explanation! Once again, I really appreciate any help that anyone can
offer on this.

Thanks,
Alex







.