[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

How to Authenticate against the Windows NT Domain via Ruby

ChessMess

6/16/2008 2:19:00 PM

We are running a Rails application on Linux RedHat with a requirement
to validate users against a Windows NT Domain (single sign-on
scenario). Some sites use LDAP, others do not. Is there any Ruby
libraries or code samples that make this an easy thing to do? Anyone
have any recommendations on ways to get this implemented?

Thanks!
11 Answers

Kyle Schmitt

6/16/2008 3:12:00 PM

0

Windows NT domain? I dunno what libraries are available, but I'd
start with looking at samba. Also it may not be a ruby-level issue,
maybe it's something that can be setup on the web server side of
things? Just a thought.

On Mon, Jun 16, 2008 at 9:19 AM, ChessMess <chessmess@gmail.com> wrote:
> We are running a Rails application on Linux RedHat with a requirement
> to validate users against a Windows NT Domain (single sign-on
> scenario). Some sites use LDAP, others do not. Is there any Ruby
> libraries or code samples that make this an easy thing to do? Anyone
> have any recommendations on ways to get this implemented?
>
> Thanks!
>
>

miles.sterrett@gmail.com

6/16/2008 5:27:00 PM

0

On Jun 16, 10:19 am, ChessMess <chessm...@gmail.com> wrote:
> We are running a Rails application on Linux RedHat with a requirement
> to validate users against a Windows NT Domain (single sign-on
> scenario). Some sites use LDAP, others do not. Is there any Ruby
> libraries or code samples that make this an easy thing to do? Anyone
> have any recommendations on ways to get this implemented?
>
> Thanks!

In our Apache config:

# Require authentication via LDAP
<Location "/">

AuthzLDAPAuthoritative off
AuthType Basic
AuthName "Restricted Area"
AuthBasicProvider ldap
AuthLDAPBindDN webapp@domain.local
AuthLDAPBindPassword cr@zypa55w0rd
AuthLDAPURL ldaps://server.domain.local:3269/dc=domain,dc=local?sAMAccountName?sub?(objectClass=*)

require valid-user
</Location>

.... which is within a <VirtualHost> definition. You'll want to
replace some things (such as 'server' and 'domain') with things
specific to your configuration.

You can then retrieve the user name via
request.env['HTTP_REMOTE_USER'] in your Rails application.

vc

6/16/2008 6:26:00 PM

0

ChessMess wrote:

> We are running a Rails application on Linux RedHat with a requirement
> to validate users against a Windows NT Domain (single sign-on
> scenario).

I'm using kerberos to do this, with mod_auth_kerb. If you have any specific
questions just ask :)

--
http://s2.d...

Vladimir Konrad

6/17/2008 6:53:00 PM

0


I am able to do this at the work-place using ruby net/ldap library. If
LDAP bind succeeds, one is authenticated user...

Hope this helps,

Vlad

PS: The net/ldap can also do this over SSL...

Kyle Schmitt

6/17/2008 8:18:00 PM

0

Vladimir,
I don't know what his actual situation is, but back in the bad old
NT4 domain days, there was no LDAP part of it at all. I know, we're
still using an NT4 domain at work.

--Kyle

On Tue, Jun 17, 2008 at 1:53 PM, Vladimir Konrad <vk@dsl.pipex.com> wrote:
>
> I am able to do this at the work-place using ruby net/ldap library. If
> LDAP bind succeeds, one is authenticated user...
>
> Hope this helps,
>
> Vlad
>
> PS: The net/ldap can also do this over SSL...
>
>

Vladimir Konrad

6/18/2008 6:57:00 PM

0

> I don't know what his actual situation is, but back in the bad old
> NT4 domain days, there was no LDAP part of it at all. I know, we're
> still using an NT4 domain at work.

Aha, well, I do not know much about NT4 domains (or AD), but I thought
that AD always had LDAP compatibility...

More info would help...

Vlad

PS: If ChessMess posts more info, I can post, if relevant, working code
(it is for ramaze, but it is a start).

Kyle Schmitt

6/18/2008 7:50:00 PM

0

On Wed, Jun 18, 2008 at 1:58 PM, Vladimir Konrad <vk@dsl.pipex.com> wrote:
>> I don't know what his actual situation is, but back in the bad old
>> NT4 domain days, there was no LDAP part of it at all. I know, we're
>> still using an NT4 domain at work.
>
> Aha, well, I do not know much about NT4 domains (or AD), but I thought
> that AD always had LDAP compatibility...
You're right, AD is basically LDAP+Kerberos and a whole lotta
microsoft anti-standards, but NT4 and earlier didn't use any of that.
It was just it's own thing.

Clifford Heath

6/19/2008 12:36:00 AM

0

Kyle Schmitt wrote:
> On Wed, Jun 18, 2008 at 1:58 PM, Vladimir Konrad <vk@dsl.pipex.com> wrote:
>>> I don't know what his actual situation is, but back in the bad old
>>> NT4 domain days, there was no LDAP part of it at all. I know, we're
>>> still using an NT4 domain at work.
>> Aha, well, I do not know much about NT4 domains (or AD),

NT4 authenticates using NTLM, a fairly straight-forward password-based
challenge-authentication mechanism.

>> but I thought that AD always had LDAP compatibility...
> You're right, AD is basically LDAP+Kerberos and a whole lotta
> microsoft anti-standards,

You're quite wrong to bash MS over this. It's true they made
one small extension to the Kerberos standard and didn't publish
it until after they got bashed up about it, but the actual
change they made corrected a deficiency in the Kerberos standard
itself, by providing a list of group memberships in the TGT
(Ticket Granting Ticket, the result of the AP, Authentication
Protocol). The "tokenGroups" attribute gets propagated to the
service tickets issued in later exchanges,

Without group memberships in the tickets, every service must keep
a separate access rights (authorization) database with an entry
for every user, or refer back to the Kerberos server whenever any
authorization question must be decided. Both alternatives are
fundamentally at odds with the original design goals of Kerberos
itself, and is a serious flaw in its design.

The structure of the tokenGroups (a list of SIDs) isn't what an
open process would have designed (names would have been used
instead of numbers), but it was pragmatic, and being relevant
only to the NT4 security model, they thought it wasn't necessary
to publish it. Had the standard not had this deficiency, I'm
confident MS would have used it without change.

MS' decision to use Kerberos was actually the right thing to do
and has definitely helped the cause of Kerberos and of greater
IT security. It reflects a move away from their earlier policy
of always using solutions they own (either by making or acquiring).
I can believe MS guilty of much of the evil of which they're
accused, but I think this one at least was an honest mistake.

Clifford Heath.

Kyle Schmitt

6/19/2008 1:21:00 PM

0

On Wed, Jun 18, 2008 at 6:38 PM, Clifford Heath <no@spam.please.net> wrote:
> You're quite wrong to bash MS over this. It's true they made
> one small extension to the Kerberos standard and didn't publish
> it until after they got bashed up about it, but the actual
> change they made corrected a deficiency in the Kerberos standard
> itself, by providing a list of group memberships in the TGT
> (Ticket Granting Ticket, the result of the AP, Authentication
> Protocol). The "tokenGroups" attribute gets propagated to the
> service tickets issued in later exchanges,
>
> Without group memberships in the tickets, every service must keep
> a separate access rights (authorization) database with an entry
> for every user, or refer back to the Kerberos server whenever any
> authorization question must be decided. Both alternatives are
> fundamentally at odds with the original design goals of Kerberos
> itself, and is a serious flaw in its design.

Humm, I've never thought about it in that respect before. But
wouldn't the more appropriate thing be to have group memberships and
service rights stored in the LDAP portion, and only use Kerberos for
the authentication?


--Kyle

Clifford Heath

6/20/2008 12:46:00 AM

0

Kyle Schmitt wrote:
> On Wed, Jun 18, 2008 at 6:38 PM, Clifford Heath <no@spam.please.net> wrote:
>> Without group memberships in the tickets, every service must keep
>> a separate access rights (authorization) database with an entry
>> for every user, or refer back to the Kerberos server whenever any
>> authorization question must be decided.

> Humm, I've never thought about it in that respect before. But
> wouldn't the more appropriate thing be to have group memberships and
> service rights stored in the LDAP portion, and only use Kerberos for
> the authentication?

That requires my 2nd alternative, for each service to check group membership
by calling the LDAP server at every authorisation decision point. It's
hugely costly, and defeats the advantages of using a ticketing system in
the first place.

What AD does is to merge the LDAP and Kerberos services into one system,
which is smart since they really are tightly coupled. The group m'ships
in the tickets are fetched by Kerberos from the LDAP part during domain
logon. That itself is a very costly operation, since it involves calls
to other domains in the same domain tree, where relevant group membership
info may be stored. You definitely don't want this being done at every
decision point!

Clifford Heath.