Active Directory Specific Auth Service

[briane]

I've released a custom authentication service for Active Directory. The main feature is support for nested groups using the tokenGroups attribute available in Active Directory. You can check it out and get more info on the CodePlex project page here (http://www.codeplex.com/DekiWikiADAuth/Release/ProjectReleases.aspx).

It works for my Deki vm setup at the office, but hasn't seen rigorous testing. Try it out and let me know how it works for you.

[MaxM]

Very nice briane! I'm glad you used the DekiAuthenticationService base class as that makes life a lot easier.

Using the computed tokenGroups is also a nice touch to get the full list of cascaded groups. It's very unfortunate that it's AD centric but this may be a good feature to port over to the mindtouch implementation.

SSL support shouldn't be difficult -- you should be able to grab that directly from the GetLdapConnectionFromBindingDN method.

Nice work and thanks for the contribution! Once you have it stabilized and documented, feel free to link to it from the current docs. Stop by irc if you want to chat about it.

Max

[TimHunt]

BrianE -

Many thanks for this - it's just what I'm looking for. Unfortunately, the service will not start:



Service AD - Nested Group reset failed
unable to initialize service (blueprint not found)


This is on an almost new VM running v.8.05.2b, with the VM recently (apt-get update && apt-get upgrade)ed.

I have copied the downloaded dll into the /bin/ directory, chmod 755, and chown www-data:www-data. This makes it identical to all the other DLLs in the directory.

Any hints and tips appreciated.

Cheers,
Tim.

[briane]

Thanks! It was a snap using the base class. I kept thinking I was missing something but everything just worked. One thing that could be more clear, though, is how to get at the config - what I did works, but I feel like it is a hack. (mainly because I haven't fully grokked the the start method)

I definately think it should be ported to the mindtouch implementation, and don't think it would be too much work.

When I started work on this a few days ago I was planning on using System.DirectoryServices to do this which wouldn't have meshed well with the default client. I ended up using Novell.Directory.Ldap because (I think) the mono implementation of S.DS uses an earlier version of Novell.Directory.Ldap than you guys. I was having trouble getting dream to load the correct dependencies and decided it would be more fun to learn Novell.Directory.Ldap than to go through dll hell on linux with only a console.

I'll try and get you on irc in the next few days so we can talk about adding this to the default client.

[briane]

Tim -

Looks like there was an error on the project release page under the setup section. The web root path for the VM should have read: /var/www/deki-hayes/bin/services

Sorry for the confusion

[TimHunt]

Tim -

Looks like there was an error on the project release page under the setup section. The web root path for the VM should have read: /var/www/deki-hayes/bin/services

Sorry for the confusion

BrianE -
I've put a copy there, and it's started fine after a reboot.

Now to test!

Cheers,
Tim.

[TimHunt]

BrianE -

You have done far more than I would have been able to accomplish with C# / Active Directory. My testing of your service is progressing, but there are a couple of queries.

Background:
1. I have set up a service "AD - Nested", which mimics the "AD" service.
2. I can go to http://example.com/@api/deki/services/default/11/users/XXX (AD - Nested) and get a response such as:


<user name="XXX">
<email>XXX@example.com</email>
<displayname></displayname>
<firstname>XXX</firstname>
<lastname>YYY</lastname>
<groups>
<group name="default" />
<group name="STOS_ISG" />
<group name="G HO OEB Observation Systems All" />
<group name="STOS_SECTION" />
<group name="G HO All" />
<group name="OEB ALL" />
<group name="Domain Users" />
<group name="Users" />
</groups>
</user>


3. when I go to group management I can not find any of these groups to add with the "AD - Nested" service. They are all available to the "AD" service.
4. If I enable a group under the "AD" service its permissions work with the "AD - Nested" service.
5. If I disable the "AD" service (4) still applies.

I'd like to *remove* the "AD" service and only have the "AD - Nested" service, so that users have a single choice of login, but this seems to remove the means of managing the Active Directory group permissions.

Is this the expected behaviour, or have I missed something in the setup?

Cheers,
Tim.

[briane]

I spaced out and forgot to implement GetGroups for Version 1.00. I released version 1.01 and it should retrieve groups. The link above should take you to Version 1.01. Just overwrite version 1.00 in the services directory and restart deki (/etc/init.d/dekiwiki restart).

[TimHunt]

I spaced out and forgot to implement GetGroups for Version 1.00. I released version 1.01 and it should retrieve groups. The link above should take you to Version 1.01. Just overwrite version 1.00 in the services directory and restart deki (/etc/init.d/dekiwiki restart).
That did the trick. Now I get a message "Group XXXXXX already exists under service 10" which is to be expected.

Many thanks.

[briane]

I wonder if this situation is a possible security issue. If some one has two auth services setup and both auth services have groups with the same name, a person in one auth service might get access to something they shouldn't have because they are in a group with the same name as one that had been given permissions from the other auth service.

I'm not sure it would affect a lot of people, but I think I remember reading on these forums where someone has setup two ldap auth services to allow access for two separate domains.

[MaxM]

If some one has two auth services setup and both auth services have groups with the same name, a person in one auth service might get access to something they shouldn't have because they are in a group with the same name as one that had been given permissions from the other auth service.


Nope this shouldn't happen. Group associations are done by ID instead of name. So if group x has admin role and is removed and group x is added from a different external provider, the old members of x are not part of the new group.

[TimHunt]

BrianE -

I am able to create users with expected permissions based on nested groups, but the displayname-pattern is not being picked up from the config. I am seeing the samAccountName.

The users table of the database shows that 'user_real_name' is being correctly drawn from AD, and a glance through your code shows that I've got the right key.

Any suggestions?

Cheers,
Tim.