Beginner Guidance

NTDEV
1

Hello, I’ve been a professional product developer for over 20 years and
have only dabbled in device drivers many moons ago. I’m in need of guidance
and direction on the basic tasks needed to accomplish a challenge we’re
facing.

Some history, our main product is based on RPC for client/server
communication. RPC uses some underlying protocols to authenticate incoming
clients. The problem is our users aren’t Windows users and currently we
must create a Windows account and associate it with our internal user. This
causes some problems for users which must remember an extra set of credentials
to access the RPC server. Microsoft has published protocol details of their
NTLM and Kerberos authentication which is quite lengthy. They’ve also
published the domain trust and other authentication details. The overall
design is to create a domain trust and expose our server as an NT domain
authority which users authenticate against natively as an NT domain.
Implementing the domain authority is a sizable task on it’s own, but the
current task which I’ve not fully figured out is implementing the low level
network protocols without interfering with Windows. The authentication
protocols exist at a lower level in the OSI model and uses ports already
reserved and in use by Windows. NT authentication is performed by the OS
and can’t be interfered with. It seems I need a virtual NIC and a separate
IP address which doesn’t interfere with Windows yet allows us to capture and
implement some lower level transport protocols. If my assumptions are
correct, please help point me in the right direction on which technologies I
need to further research. This DDK is massive and not my domain of
expertise, any help is appreciated.

–
David Mott

Disclaimer: This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

2

>underlying protocols to authenticate incoming clients. The problem is our users aren’t Windows users

This is your core problem.

The best way of solving this is to go the way SQL Server went around 17 years ago, and introduce the “Integrated Windows Security” mode to your product.

Look at how SQL Server does this. In usual mode, it has its own user list and its own auth logic. In Windows Integrated Security, its user list keeps no passwords and is a row-to-row replica of Window’s user list (keeping only SQL-specific data), and it uses the Windows/RPC auth mechanisms.

Reimplementing LDAP and Kerberos just to solve such a task is a massive overkill, probably 10 times more complex then the proper solution.

The proper solution is something like a:

a) add the “Windows SID” column to your’ product’s user list table
b) this column is usually NULL, but, for “Windows Integrated” users, it will be the actual SID
c) there must be some admin tools (and some paradigm of administering this) to populate the SID value for your users. For instance, bulk import of the whole domain’s user list to your product, with the SID value to associate your user record to the domain’s one.
d) your product server code must use RpcImpersonateClient+OpenThreadToken+GetTokenInformation to get the client’s user SID.
c) your product client code in Windows Integrated Security mode must use RpcBindingSetAuthInfo to push the username/password (if the user have explicitly provided them) to the RPC core. If you will not do this - then the current interactive Windows user of the client machine will be used, which is OK for most tasks. Things like Outlook do exactly this.

Another solution is to go Exchange Server’s way. I.e. drop your own user list totally, and move all its data to the Active Directory itself. For this, you must write a forest preparation tool which will update the AD’s user list schema to add your product’s fields to it.

After this, all user administration tools of your product must be rewritten to use AD’s APIs.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

3

Maxim, thanks for the reply, a few comments.

The best way of solving this is to go the way SQL Server went around 17
years ago, and introduce the “Integrated Windows Security” mode to your
product.

This is what we presently have and it is the problem. Our users are not
Windows users and never will be homed as Windows users. As a work around we
must create a Windows user so RPC will authenticate them which is
undesirable. We’ve got it working with impersonation and so forth, our
solution for discovering the authenticated user is a little more simple,
using the authentication callback in RpcServerRegisterIfEx passes a unicode
string of the authenticated user in the Context parameter in the form of:
domain\login so we only need the text domain\login mapping.

Reimplementing LDAP and Kerberos just to solve such a task is a massive
overkill…

Understood, fortunately I have an open ended commitment to get it done and a
proper implementation opens a huge potential for our servers and market.
Getting the RPC to authenticate is the edge case, there’s a great deal more
we intend to accomplish with a functional solution. We already have LDAP,
Kerberos and CA servers in our main product which will need some tweaking to
support Microsoft’s extensions so it won’t be built entirely from the ground
up. We have several design constraints and must work within them. One is
the users cannot be AD users. From my understanding the way around this is
to create a system that acts as a trusted domain which Windows trusts to
authenticate against instead of AD. The protocols are well defined, I just
cannot begin implementing them without interfering with the OS which already
has the ports reserved for internal use. I believe a vlan is the way to go,
just don’t have the expertise or know what portions of the DDK to research.
It will no doubt be a massive project and take a good number of man years to
achieve and probably create a few jobs, but I’ve got the approval to do it,
just don’t know where to begin research on working with TCP/IP at it’s lower
levels without interfering with the OS.

Any help is appreciated, thanks in advance.

David Mott

Disclaimer: This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

4

In that case, it sounds like what you really want is for a user to be
able to login to Windows using credentials from your proprietary
server. In other words, you want Windows to be able to authenticate
to you. That way you don’t have to rewrite Rpc or LDAP. What you
want to write is called an LSA, a Local Security Authority.

I had a similar issue at my previous company. They wanted SSO for
users of a Tomcat webapp using CAS and a Windows client/server app.
Writing an LSA certainly sounded interesting to me, but it turned out
that in all cases they would have an AD server and did not really have
two separate directories, so it was much easier, although less
interesting, to add NTLM support to CAS and proxy credentials from the
Windows client to CAS for Windows->Tomcat. Tomcat->Windows was easy
because the Windows app authenticated to its own server anyway,
maintaining a separate SID from that of the current Windows user. So
all we had to do was have webapp get a ticket, provide it to our
ActiveX control, then verify the ticket and lookup the username, and
finally resolve that to a SID. Otherwise, I would have needed to
proxy NTLM the other direction too.

As a brief aside, you may ask, why NTLM and not Kerberos? Because
NTLM doesn’t require policy changes, works out of the box everywhere,
and needs no setup. It turns out to be used in many places because of
that. Just be sure to use NTLM2 as it is more secure.

An LSA is a user-mode DLL, so if you go this route you’ll want to post
further questions elsewhere. Writing an LSA is a non-trivial
undertaking: they are not real well documented and debugging will
likely have some difficulties. I recommend disabling UAC to start, or
better yet writing it on XP and then adding Vista+ support. LSA’s do
more than just handling login/logout. I seem to recall that Windows
2000+ supports an LSA “light”, one that is intended for just such a
thing as you’re doing since that is what most developers needed, but
it has been a while and my mind could be inventing wishful fantasies.

I hope this provides useful direction, or at least food for thought.
Personally I would probably do this by making your app able to
authenticate to Windows instead and then adding a tool for initial
directory population. Things just work easier that way. But then I
know only like 100 characters about your system. Have fun!

David L-

On 12/10/10, David Mott wrote:
> Maxim, thanks for the reply, a few comments.
>
>> The best way of solving this is to go the way SQL Server went around 17
> years ago, and introduce the “Integrated Windows Security” mode to your
> product.
>
> This is what we presently have and it is the problem. Our users are not
> Windows users and never will be homed as Windows users. As a work around we
> must create a Windows user so RPC will authenticate them which is
> undesirable. We’ve got it working with impersonation and so forth, our
> solution for discovering the authenticated user is a little more simple,
> using the authentication callback in RpcServerRegisterIfEx passes a unicode
> string of the authenticated user in the Context parameter in the form of:
> domain\login so we only need the text domain\login mapping.
>
>>Reimplementing LDAP and Kerberos just to solve such a task is a massive
> overkill…
>
> Understood, fortunately I have an open ended commitment to get it done and a
> proper implementation opens a huge potential for our servers and market.
> Getting the RPC to authenticate is the edge case, there’s a great deal more
> we intend to accomplish with a functional solution. We already have LDAP,
> Kerberos and CA servers in our main product which will need some tweaking to
> support Microsoft’s extensions so it won’t be built entirely from the ground
> up. We have several design constraints and must work within them. One is
> the users cannot be AD users. From my understanding the way around this is
> to create a system that acts as a trusted domain which Windows trusts to
> authenticate against instead of AD. The protocols are well defined, I just
> cannot begin implementing them without interfering with the OS which already
> has the ports reserved for internal use. I believe a vlan is the way to go,
> just don’t have the expertise or know what portions of the DDK to research.
> It will no doubt be a massive project and take a good number of man years to
> achieve and probably create a few jobs, but I’ve got the approval to do it,
> just don’t know where to begin research on working with TCP/IP at it’s lower
> levels without interfering with the OS.
>
> Any help is appreciated, thanks in advance.
> –
>
> David Mott
> –
>
>
>
>
> Disclaimer: This transmission (including any attachments) may contain
> confidential information, privileged material (including material protected
> by the solicitor-client or other applicable privileges), or constitute
> non-public information. Any use of this information by anyone other than
> the intended recipient is prohibited. If you have received this
> transmission in error, please immediately reply to the sender and delete
> this information from your system. Use, dissemination, distribution, or
> reproduction of this transmission by unintended recipients is not authorized
> and may be unlawful.
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

–
Sent from my mobile device

5

Hi David, thanks for the reply. I experimented with LSA several months ago
but it doesn’t really provide what the documents infer. I opened a support
ticket with Microsoft and they indicated as much, said it was misleading and
would be removed in future platform SDKs. It seems it only allows an
application to enlist in the login process and get some information about
logins but doesn’t really allow Windows to authenticate logins to 3rd party
sources like we need. It also allows a vendor to create different types of
logins such as retinal scanners, finger print scanners, etc but the users
must still reside in the SAM or AD.

Another challenge we have is nothing can be installed on the client machine
and we can’t modify the RPC client app. The OS implements the various login
and authentication protocols natively and has these ports already reserved.
It expects them to work so we cannot just hijack the ports without screwing
up the OS. Thats why I think a virtual lan is the way to go and piggy back
on the existing NIC or require a dedicated NIC on the server. This way we
can implement the (massive) domain trust and authentication protocols
without interfering with the OS and the OS will assume it’s communicating
with a separate NT domain. My difficulty is the lack of DDK expertise and
finding out what exactly is needed to create a virtual LAN and getting IP
fragments off the wire, etc. Virtual machine apps do something similar to
provide NICs to VMs.

Any direction is greatly appreciated,

David Mott

-----Original Message-----
From: David Luxford
To: “Windows System Software Devs Interest List”
Date: Sat, 11 Dec 2010 05:55:06 -0500
Subject: Re: [ntdev] Beginner Guidance

In that case, it sounds like what you really want is for a user to be
able to login to Windows using credentials from your proprietary
server. In other words, you want Windows to be able to authenticate
to you. That way you don’t have to rewrite Rpc or LDAP. What you
want to write is called an LSA, a Local Security Authority.

I had a similar issue at my previous company. They wanted SSO for
users of a Tomcat webapp using CAS and a Windows client/server app.
Writing an LSA certainly sounded interesting to me, but it turned out
that in all cases they would have an AD server and did not really have
two separate directories, so it was much easier, although less
interesting, to add NTLM support to CAS and proxy credentials from the
Windows client to CAS for Windows->Tomcat. Tomcat->Windows was easy
because the Windows app authenticated to its own server anyway,
maintaining a separate SID from that of the current Windows user. So
all we had to do was have webapp get a ticket, provide it to our
ActiveX control, then verify the ticket and lookup the username, and
finally resolve that to a SID. Otherwise, I would have needed to
proxy NTLM the other direction too.

As a brief aside, you may ask, why NTLM and not Kerberos? Because
NTLM doesn’t require policy changes, works out of the box everywhere,
and needs no setup. It turns out to be used in many places because of
that. Just be sure to use NTLM2 as it is more secure.

An LSA is a user-mode DLL, so if you go this route you’ll want to post
further questions elsewhere. Writing an LSA is a non-trivial
undertaking: they are not real well documented and debugging will
likely have some difficulties. I recommend disabling UAC to start, or
better yet writing it on XP and then adding Vista+ support. LSA’s do
more than just handling login/logout. I seem to recall that Windows
2000+ supports an LSA “light”, one that is intended for just such a
thing as you’re doing since that is what most developers needed, but
it has been a while and my mind could be inventing wishful fantasies.

I hope this provides useful direction, or at least food for thought.
Personally I would probably do this by making your app able to
authenticate to Windows instead and then adding a tool for initial
directory population. Things just work easier that way. But then I
know only like 100 characters about your system. Have fun!

David L-

On 12/10/10, David Mott wrote:
> Maxim, thanks for the reply, a few comments.
>
>> The best way of solving this is to go the way SQL Server went around 17
> years ago, and introduce the “Integrated Windows Security” mode to your
> product.
>
> This is what we presently have and it is the problem. Our users are not
> Windows users and never will be homed as Windows users. As a work around
we
> must create a Windows user so RPC will authenticate them which is
> undesirable. We’ve got it working with impersonation and so forth, our
> solution for discovering the authenticated user is a little more simple,
> using the authentication callback in RpcServerRegisterIfEx passes a
unicode
> string of the authenticated user in the Context parameter in the form of:
> domain\login so we only need the text domain\login mapping.
>
>>Reimplementing LDAP and Kerberos just to solve such a task is a massive
> overkill…
>
> Understood, fortunately I have an open ended commitment to get it done and
a
> proper implementation opens a huge potential for our servers and market.
> Getting the RPC to authenticate is the edge case, there’s a great deal
more
> we intend to accomplish with a functional solution. We already have LDAP,
> Kerberos and CA servers in our main product which will need some tweaking
to
> support Microsoft’s extensions so it won’t be built entirely from the
ground
> up. We have several design constraints and must work within them. One is
> the users cannot be AD users. From my understanding the way around this
is
> to create a system that acts as a trusted domain which Windows trusts to
> authenticate against instead of AD. The protocols are well defined, I
just
> cannot begin implementing them without interfering with the OS which
already
> has the ports reserved for internal use. I believe a vlan is the way to
go,
> just don’t have the expertise or know what portions of the DDK to
research.
> It will no doubt be a massive project and take a good number of man years
to
> achieve and probably create a few jobs, but I’ve got the approval to do
it,
> just don’t know where to begin research on working with TCP/IP at it’s
lower
> levels without interfering with the OS.
>
> Any help is appreciated, thanks in advance.
> –
>
> David Mott
> –
>
>
>
>
> Disclaimer: This transmission (including any attachments) may contain
> confidential information, privileged material (including material
protected
> by the solicitor-client or other applicable privileges), or constitute
> non-public information. Any use of this information by anyone other than
> the intended recipient is prohibited. If you have received this
> transmission in error, please immediately reply to the sender and delete
> this information from your system. Use, dissemination, distribution, or
> reproduction of this transmission by unintended recipients is not
authorized
> and may be unlawful.
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

–
Sent from my mobile device

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Disclaimer: This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

6

“David Mott” wrote in message news:xxxxx@ntdev…
…
> The OS implements the various login
> and authentication protocols natively and has these ports already
> reserved.
> It expects them to work so we cannot just hijack the ports without
> screwing
> up the OS. Thats why I think a virtual lan is the way to go and piggy
> back
> on the existing NIC or require a dedicated NIC on the server.

This approach indeed lets you to hook on traffic on these ports.
Virtual LAN interfaces, network filters, protocols etc are quite usual kind
of drivers.
If you have a budget and can hire for this project, it won’t be hard to find
helping hands.
At least, it looks that writing a driver is the smallest problem here :wink:

Regards,
– pa

7

Hi Pavel, thanks for taking the time to reply. Can you give me an idea of
what technologies, steps, basic outline or bullet points I should research
to get an idea of what it would take to implement this part of the project?

–
David Mott

-----Original Message-----
From: “Pavel A.”
To: “Windows System Software Devs Interest List”
Date: Sun, 12 Dec 2010 04:22:19 +0200
Subject: Re:[ntdev] Beginner Guidance

“David Mott” wrote in message news:xxxxx@ntdev…
…
> The OS implements the various login
> and authentication protocols natively and has these ports already
> reserved.
> It expects them to work so we cannot just hijack the ports without
> screwing
> up the OS. Thats why I think a virtual lan is the way to go and piggy
> back
> on the existing NIC or require a dedicated NIC on the server.

This approach indeed lets you to hook on traffic on these ports.
Virtual LAN interfaces, network filters, protocols etc are quite usual kind
of drivers.
If you have a budget and can hire for this project, it won’t be hard to find
helping hands.
At least, it looks that writing a driver is the smallest problem here :wink:

Regards,
– pa

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Disclaimer: This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

8

>Can you give me an idea of

what technologies, steps, basic outline or bullet points I should research
to get an idea of what it would take to implement this part of the project?

Aside of the main goal (which I don’t understand, I must admit)
you’ve already named these yourself?
You want to divert traffic from certain ip ports on Windows server, normally
occupied by Windows components, to your own, correct?

The simplest possible solution is NDIS protocol driver which will copy interesting
L2 packets to your app and inject packets back to the network.
Your app will need to reassemble these L2 packets to TCP, UDP and so on
(bring your own IP stack).

This assumes that Windows can receive these packets too and ignore them,
or at least it won’t be too disturbed. To hide these packets from Windows,
a more complex sort of driver is needed: “NDIS intermediate driver”.

In order to reuse Windows tcp/ip layer, the ndis level tap can
create a virtual network card and redirect the catched packets there,
also changing the port numbers to something your app can register for.
Again, this can be done with or without removing the original packets.

Hope this helps,
– pa

9

Well, that’s just @#*!

One more suggestion. You have a custom directory and want Windows
users to be able to login using those credentials. The next
suggestion is to use a directory synchronizer. There are a few
products that replicate non-Windows accounts/passwords to Windows and
vice-versa. Microsoft bought one a few years ago and has renamed it
twice. It was called Forefront and I forget what its called now.
This is a “hot” server that keeps both sides up to date continuously,
but it can be run in batch mode if you prefer. You’d probably need to
write a provider for your server/app/os/whatever it is. I’d think it
would be much easier to do that than write a vlan driver. Now, it
*would* be much more fun to write the vlan driver…

On 12/11/10, David Mott wrote:
> Hi David, thanks for the reply. I experimented with LSA several months ago
> but it doesn’t really provide what the documents infer. I opened a support
> ticket with Microsoft and they indicated as much, said it was misleading and
> would be removed in future platform SDKs. It seems it only allows an
> application to enlist in the login process and get some information about
> logins but doesn’t really allow Windows to authenticate logins to 3rd party
> sources like we need. It also allows a vendor to create different types of
> logins such as retinal scanners, finger print scanners, etc but the users
> must still reside in the SAM or AD.
>
> Another challenge we have is nothing can be installed on the client machine
> and we can’t modify the RPC client app. The OS implements the various login
> and authentication protocols natively and has these ports already reserved.
> It expects them to work so we cannot just hijack the ports without screwing
> up the OS. Thats why I think a virtual lan is the way to go and piggy back
> on the existing NIC or require a dedicated NIC on the server. This way we
> can implement the (massive) domain trust and authentication protocols
> without interfering with the OS and the OS will assume it’s communicating
> with a separate NT domain. My difficulty is the lack of DDK expertise and
> finding out what exactly is needed to create a virtual LAN and getting IP
> fragments off the wire, etc. Virtual machine apps do something similar to
> provide NICs to VMs.
>
> Any direction is greatly appreciated,
> –
> David Mott
> –
>
>
> -----Original Message-----
> From: David Luxford
> To: “Windows System Software Devs Interest List”
> Date: Sat, 11 Dec 2010 05:55:06 -0500
> Subject: Re: [ntdev] Beginner Guidance
>
> In that case, it sounds like what you really want is for a user to be
> able to login to Windows using credentials from your proprietary
> server. In other words, you want Windows to be able to authenticate
> to you. That way you don’t have to rewrite Rpc or LDAP. What you
> want to write is called an LSA, a Local Security Authority.
>
> I had a similar issue at my previous company. They wanted SSO for
> users of a Tomcat webapp using CAS and a Windows client/server app.
> Writing an LSA certainly sounded interesting to me, but it turned out
> that in all cases they would have an AD server and did not really have
> two separate directories, so it was much easier, although less
> interesting, to add NTLM support to CAS and proxy credentials from the
> Windows client to CAS for Windows->Tomcat. Tomcat->Windows was easy
> because the Windows app authenticated to its own server anyway,
> maintaining a separate SID from that of the current Windows user. So
> all we had to do was have webapp get a ticket, provide it to our
> ActiveX control, then verify the ticket and lookup the username, and
> finally resolve that to a SID. Otherwise, I would have needed to
> proxy NTLM the other direction too.
>
> As a brief aside, you may ask, why NTLM and not Kerberos? Because
> NTLM doesn’t require policy changes, works out of the box everywhere,
> and needs no setup. It turns out to be used in many places because of
> that. Just be sure to use NTLM2 as it is more secure.
>
> An LSA is a user-mode DLL, so if you go this route you’ll want to post
> further questions elsewhere. Writing an LSA is a non-trivial
> undertaking: they are not real well documented and debugging will
> likely have some difficulties. I recommend disabling UAC to start, or
> better yet writing it on XP and then adding Vista+ support. LSA’s do
> more than just handling login/logout. I seem to recall that Windows
> 2000+ supports an LSA “light”, one that is intended for just such a
> thing as you’re doing since that is what most developers needed, but
> it has been a while and my mind could be inventing wishful fantasies.
>
> I hope this provides useful direction, or at least food for thought.
> Personally I would probably do this by making your app able to
> authenticate to Windows instead and then adding a tool for initial
> directory population. Things just work easier that way. But then I
> know only like 100 characters about your system. Have fun!
>
> David L-
>
> On 12/10/10, David Mott wrote:
>> Maxim, thanks for the reply, a few comments.
>>
>>> The best way of solving this is to go the way SQL Server went around 17
>> years ago, and introduce the “Integrated Windows Security” mode to your
>> product.
>>
>> This is what we presently have and it is the problem. Our users are not
>> Windows users and never will be homed as Windows users. As a work around
> we
>> must create a Windows user so RPC will authenticate them which is
>> undesirable. We’ve got it working with impersonation and so forth, our
>> solution for discovering the authenticated user is a little more simple,
>> using the authentication callback in RpcServerRegisterIfEx passes a
> unicode
>> string of the authenticated user in the Context parameter in the form of:
>> domain\login so we only need the text domain\login mapping.
>>
>>>Reimplementing LDAP and Kerberos just to solve such a task is a massive
>> overkill…
>>
>> Understood, fortunately I have an open ended commitment to get it done and
>>
> a
>> proper implementation opens a huge potential for our servers and market.
>> Getting the RPC to authenticate is the edge case, there’s a great deal
> more
>> we intend to accomplish with a functional solution. We already have LDAP,
>> Kerberos and CA servers in our main product which will need some tweaking
> to
>> support Microsoft’s extensions so it won’t be built entirely from the
> ground
>> up. We have several design constraints and must work within them. One is
>> the users cannot be AD users. From my understanding the way around this
> is
>> to create a system that acts as a trusted domain which Windows trusts to
>> authenticate against instead of AD. The protocols are well defined, I
> just
>> cannot begin implementing them without interfering with the OS which
> already
>> has the ports reserved for internal use. I believe a vlan is the way to
> go,
>> just don’t have the expertise or know what portions of the DDK to
> research.
>> It will no doubt be a massive project and take a good number of man years
> to
>> achieve and probably create a few jobs, but I’ve got the approval to do
> it,
>> just don’t know where to begin research on working with TCP/IP at it’s
> lower
>> levels without interfering with the OS.
>>
>> Any help is appreciated, thanks in advance.
>> –
>>
>> David Mott
>> –
>>
>>
>>
>>
>> Disclaimer: This transmission (including any attachments) may contain
>> confidential information, privileged material (including material
> protected
>> by the solicitor-client or other applicable privileges), or constitute
>> non-public information. Any use of this information by anyone other than
>> the intended recipient is prohibited. If you have received this
>> transmission in error, please immediately reply to the sender and delete
>> this information from your system. Use, dissemination, distribution, or
>> reproduction of this transmission by unintended recipients is not
> authorized
>> and may be unlawful.
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>
> –
> Sent from my mobile device
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> Disclaimer: This transmission (including any attachments) may contain
> confidential information, privileged material (including material protected
> by the solicitor-client or other applicable privileges), or constitute
> non-public information. Any use of this information by anyone other than
> the intended recipient is prohibited. If you have received this
> transmission in error, please immediately reply to the sender and delete
> this information from your system. Use, dissemination, distribution, or
> reproduction of this transmission by unintended recipients is not authorized
> and may be unlawful.
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

–
Sent from my mobile device

10

> Now, it *would* be much more fun to write the vlan driver…

+1

We are talking about creating couple of kernel jobs for an year or more :slight_smile: Buying some COTS product isn’t cool.
– pa

11

Who knows what his app does, how its used, and the impact of this
functionality. Maybe more jobs get created with COTS. Been there,
done that - lotsa people get laid off solving problems badly.

I agree -kernel dev jobs good.

David L-

On 12/12/10, xxxxx@fastmail.fm wrote:
>> Now, it would be much more fun to write the vlan driver…
>
> +1
>
> We are talking about creating couple of kernel jobs for an year or more :slight_smile:
> Buying some COTS product isn’t cool.
> – pa
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

–
Sent from my mobile device

12

>Another challenge we have is nothing can be installed on the client machine and we can’t modify the

RPC client app. The OS implements the various login and authentication protocols natively and has
these ports already reserved.

So, you’re making a kernel-mode driver instead of app patches?

Extremely bad way to go. You’re producing the fragile misdesigned software and will surely get the support nightmare when you will deploy it.

Making virtual LANs opens you to dependency on network settings on each customer’s site, and yes, you will need to support the network config issues of your customers.

Sorry, but patching the client app is - I would say - 10 times easier in terms of both development and support. The support side of things will be “just replace these DLLs with the new ones provided on our partner’s website” or even “just run this .MSI”.

More so. To avoid the huge project of developing your own domain controller software, you can just plain embed a dedicated Windows domain controller to your software deployment policy. Yes, just a special dedicated Windows domain for your software only. This is surely more reliable then developing your own DC/AD software and resolving the support issues with it.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

13

>basic outline or bullet points I should research to get an idea of what it would take to implement this

part of the project?

  1. talk to your HR about recruiting at least twice more people to your company’s technical support department, and this new hire must require strong network administration skills.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

14

> We are talking about creating couple of kernel jobs for an year or more :slight_smile:

At least.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

15

Hi David,

The next suggestion is to use a directory synchronizer.

This is what we presently have and it works, but it’s the problem. It’s
undesirable for the users to exist in AD. The users will never be ‘homed’
or originate in AD so we must create an AD user so RPC will authenticate.
This is more of a problem with RPC IMO or lack of 3rd party authentication
mechanisms in Windows.

–
David Mott
Product Developer
Alt-N Technologies
A Subsidiary of Research In Motion
http://www.altn.com

Disclaimer: This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

16

Hi Maxim,

patching the client app is - I would say - 10 times easier

I agree but it’s not an option. There is additional value-add with a
functional domain authority beyond just RPC authentication.

embed a dedicated Windows domain controller_ to your software deployment
policy.

I don’t think this will work. We need to host potentially hundreds of
domains from a single server.

–
David Mott

Disclaimer: This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

17

>authenticate. This is more of a problem with RPC IMO or lack of 3rd party authentication

mechanisms in Windows.

Network auth is a thing which is complex to do properly. So, Windows only supports industry-standard protocols for this, like Kerberos.

This is only the client and network side of things, you can probably use Windows with non-MS Kerberos server (I would google for this, or maybe experiment with some open-source Kerberos server before starting coding).

Also, I cannot understand why you need to meddle into the network stack for Kerberos.

I surely know that you can have 2 DCs on the same network, for different domains, and the auth will work for both of them - just use the correct domain prefix/suffix.

“Your users” will have another domain name then Windows users, and your DC (your own proprietary code) will coexist on the same network with Windows DC.

For RPC auth to work, probably it is enough to only implement Kerberos in your DC, since you do not need to, say, run interactive user sessions as “your user” (this can require much more then Kerberos, for HKCU registry and for home directories, probably the Windows shell uses LDAP to locate them in the domain environment).

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

18

Hi Maxim, thanks for the reply.

you can probably use Windows with non-MS Kerberos server

I tried this a couple years ago and sadly it doesn’t work. The MS
implementation isn’t exactly standard. I’ll look again, I believe MS has
since released details on their implementation. Yay E.U.

I cannot understand why you need to meddle into the network stack for
Kerberos.

Consider ISPs which host potentially hundreds of domains to thousands of
users. A separate DC/OS installation per domain, the hardware and software
costs, licenses, maintenance, etc is unrealistic. Assuming Kerberos doesn’t
work and an domain trust is required. We want our server apps to run on one
box, however, the ports used by the domain trust and authentication
protocols are already in-use by the OS. Thats why I think a vlan is the way
to go to do a sort of loop back and implement them at the higher levels
without interfering with the OS’s side of the protocols.

The size/scope/complexity of a proper solution is not really a problem. The
simpler the better IMO but everything I’ve looked at short of a virtual lan
and domain trust doesn’t work. I’ve got great support from the money men
and decision makers to make it work within the constraints. At this stage
I’m gathering requirements and estimating man hours, cost, impact, etc.

Thanks for your help,

David Mott

Disclaimer: This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.