[Work In Progress] LDAP Authentication

9/23/2005 10:49:51 AM

TJ Fontaine

Total Posts 36

View Posts

[This is not currently in SVN nor published anywhere]

Current Status:
    Each site can be deployed with different LDAP Settings (server, port, bind dn, user base dn, group base dn)
    Authentication works
    Member List Works
    Profile Works

Working on:
    Cleaning up Groups/Roles
    Site admins stored in DB
    Tracking forum posts and other per user info via DB

I've tried to keep to a minimum the number api breaking changes I've introduced. I've added into SiteSettings a public property that handles per site LdapSettings (a class added into mojoPortal.Business), along with a boolean UseLdapAuth. The other significant change is places dealing with users and or groups where a simple SiteSettings.SiteID was passed you now pass the whole SiteSettings so mojoPortal.Business (in particularly SiteUser) can handle determining whether or not you're using LDAP or standard DB or some other means. I have added a class LdapManagement (it relys on Novell.Directory.Ldap which is distributed with Mono by default) to mojoPortal.Business which is designed to handle essentially what mojoPortal.dbPortal does for users and roles.

While working on this I realized how easy it was to make the code specific to my setup, so basically I'm asking for comments on how the maintainers feel the previous areas should be handled, along with a few more issues I've been pondering. The main issue is schema mapping, I would imagine that most who've implemented openldap+samba+pam have roughly similar setups, but would it be helpful to create an Ldap Configuration module that would handle which attributes map to different pieces of a users profile, or handle defualt group mappings to existing roles, etc etc. I suppose we could for specific mojoPortal details distribute a schema that extends and adds the fields we want/need.

Also if there are any other caveats you can think of with regards to LDAP integration I would certianly be glad to hear them. I hope to publish the first diff of my work by the end of next week.

9/23/2005 1:45:48 PM

Dean Brettle

Total Posts 148

View Posts

Re: [Work In Progress] LDAP Authentication

Sounds very interesting. I don't have any plans to use it myself, but I suspect others would find it useful. My primary concern is that it not make deployment any more complicated for users who aren't using LDAP. To that end, I'd recommend hiding LdapSettings and LdapManagement behind interfaces (IAuthSettings and IAuthManagement?) and providing implementations that work with the DB (DBAuthSettings and DBAuthManagement?).

Just my $.02. Joe is the one with the power to accept/reject, so he's the one that matters. :-)

--Dean

9/23/2005 3:24:27 PM

Joe Audette

Total Posts 18439

View Posts

Re: [Work In Progress] LDAP Authentication

TJ,

Thanks for taking on this project!

I'm all for supporting LDAP authentication, its been on the planned feature list all along and I have no doubt we can implement it without making things difficult for users who are sticking with db authentication.

When you send me your changes I will try to work with you to arrive at something mutually acceptable that meets the above criteria.
I also want to implement authentication against Active Directory and I have a working implementation in one of my projects at work. It still uses Forms authentication but it authenticates against AD and then uses the Forms Auth methods for creating the authentication ticket with encrypted roles retrieved from AD. This works pretty well because you don't have to query AD any more for the rest of the session. I was planning to do something similar for mojoportal but I've been pondering the roles issues and thinking I might maintain roles in the db because they are site related roles. So in other words authenticate against AD or LDAP but authorize from the db. I envisioned if a user authenticated I would check the site users table for a matching user and if not found create one. Then no changes are needed for things like member list, it would still populate from the db. Sounds like you are populating Member list directly from ldap?

The main reason I'm thinking of managing roles in the db is that there are a few roles that mojoportal expects to be there which may not exist in the domain, specifically Admins, Content Administrators, Authenticated Users. I've made it so that there is a separate role display name so if users want to rename the role for localization purposes it changes the display but under the hood it doesn't change so nothing breaks. Even if there happen to be corresponding roles in the domain they may not corelate to who you want to be able to do what in the site.

I'm open to discussion on these things but this has been my thinking on a simple way to implement this. I'm not sure whether its possible to write a single ldap implementation that works both with Novell and AD so we will probably need to use a provider model or some mechanism to be able to easily use either one. It would be nice to support OpenLDAP as well.

Can you run the Novell code on Windows with the .NET framework or only with mono? If so please give me some info on what I have to do to set that up so I will be able to test your work. I also have a Suse 9.3 machine that I could probably setup a Novell Domain on for testing but any instructions you can provide or point me too will be helpful when you send me the code since I've never worked with that before.

Anyway this will be an important feature to have and we definitly will have it in some form.

I'll look forward to your patch.

Joe

9/24/2005 6:34:58 AM

TJ Fontaine

Total Posts 36

View Posts

Re: [Work In Progress] LDAP Authentication

Woo Hoo always glad to see positive responses!

First things first, in response to Dean:

As is the implementation doesn't directly impede on anyone trying to deploy without using Ldap, it merely becomes a check box and a few textboxes on the admin/SiteSettings page, that being said having some nice generic interfaces to handle any future authentication methods would indeed be preferable. For now though I'm going to get it into a much more workable state and see what Joe has to say.

And now for the boss:

Disclaimer, all your points you brought up are exactly why I decided to post my progress and questions so we could discuss how you wanted it to turn out.

Firstly I should have been more clear, Novell.Directory.Ldap is a .net provider to communicate with any Ldap server (even AD for that matter) I chose this method over System.Directory because System.Directory from what I could tell is aimed directly at AD and isn't fully implemented under Mono (as of now). My current setup is running on OpenLdap where my accounts inherit from inetOrgPerson, posixAccount, sambaSamAccount which I think is pretty standard for many folks running ldap for pam+samba integration as these are all schemas that are usually distributed by default with their distributions. That's just so you have more clarity as to where I'm coming from, and what I mean for specific to my site.

The Ldap authentication was shoehorned directly beside the DB Authentication, that is to say in secure/SiteLogin the only change is the passing of entire SiteSettings instead of just SiteSettings.SiteID, then SiteUser.Login looks to see if UseLdapAuth is true and if so call LdapManagement.Login(LdapSettings, email, pass) and returns the cn for displaying the userName. I didn't change anything else so I presume if DB authentication is using Forms auth then Ldap is as well.

The implementation currently does populate the member list and the user profile (the attributes I can) directly from Ldap, and for at least my uses I can't see any performance hit. That being said I had also been toying with the exact same idea of checking to see if user exists in db and if not creating them and then using that to store pertinent mojoportal information. This is especially helpful when you are considering how to manage the number of forum posts, and all the other fun pieces that tie each of the modules on a site together. Moving to a pure Ldap model would certainly cause issues as depending on what attribute you pick to identify your users it could change thus breaking ownership of modules, which in general would be a BadThing(tm). But the upside to using a pure Ldap implementation is that the possibility of duplicated attributes/profile info (and thus the number of extra pieces you have to maintain across your systems) are reduced to one more central location. Another thing to consider is user deletion, for instance do you delete a user who exists in the db but whose entry doesn't exist in Ldap or do you delete when the user exists in the db but can no longer be authenticated via Ldap, or just run a maint script that checks per site per ldap server and keeps the lists in sync.

With regards to roles, I'm all for managing roles via the DB as it reduces the complexity of Ldap implementation significantly, the only reason I was considering manging them via Ldap is that it may be possible that some organizations already have seperated their users out enough via groups that they may want to map those groups to mojoPortal roles to ease the burden of manging users. This is why I was thinking of some way to map Ldap groups directly to your default mojoPortal roles.

I suppose the best plan of attack for Ldap authentication and management would be to implement the split personality version that allows sites to authenticate via ldap but manage roles and user information via the database, and then later provide modules that could pass more control to ldap for either user info, roles or both. In any event I'm sure that with enough peer review I can create an implementation that satisfies everyones needs.

9/24/2005 7:00:41 AM

Joe Audette

Total Posts 18439

View Posts

Re: [Work In Progress] LDAP Authentication

Good deal TJ!

For the first round lets go with the db for populating the member list and profile stuff. We can talk more about if we want to follow up with deeper integration of ldap based user properties. I was hoping that maybe the novell ldap would also work with AD, glad to know it is possible. The implementation I have done before is with the System.Directory and I knew that wouldn't work with Novell or OpenLDAP. This is great news that we can use 1 implementation with all 3.
How much control does Novell.Directory.Ldap expose? Is it actually possible to update user properties from the profile page, password etc using that?

I will be able to test it with Active Directory and if you can give me or point me to a primer on OpenLDAP I will try and get setup to test that too.

I think we can leave it to the admin discretion whether to delete users from a site if they de-activate or remove them from the LDAP. I've also been thinking about the flow of installation and switch to LDAP. The installation will of course continue to default to db authentication. To convert to ldap, the admin would login and change his username to match his ldap username so that when he changes the site settings his user will still be in admins role. So I need to probably add a username field to the users table separate from the Name field which is the full name. We would have to enforce unique values per site id for this field while it is possible for 2 users to have the same value in the Name field ie John Smith.
I have been thinking that I need this anyway because not everyone wants to use email as the unique login identifier. I'm willing to implement that but don't want to slow your progress so if you add it to your db version I'll do the other 2 layers.

I've added you to a developer role in this site which gives you permission to create and edit pages beneath the Developer Area of this site that is only visible to users in this role and also under the Documentation section if you care to author any instructions for setting up the LDAP stuff at some point, feel free.

Keep in touch as needed while you progress, I'll help in any way I can.

Joe

9/24/2005 7:58:22 AM

Dean Brettle

Total Posts 148

View Posts

Re: [Work In Progress] LDAP Authentication

TJ,

I realize it's just a checkbox from an admin's perspective, but I was thinking about what would need to be installed. Won't Novell.Ldap.Directory.dll need to be installed even if LDAP isn't being used? If so, Mono users will have it but .NET users won't. So either mojoPortal releases would need to include it, or .NET users would need to install it. If mojoPortal included it, Mono users that upgrade Mono after installing mojoPortal would end up running an older-than-necessary Novell.Ldap.Directory.dll.

Perhaps, the best way to handle this is to include Novell.Ldap.Directory.dll with mojoPortal, but to recommend that Mono LDAP users remove it.

One way or the other, this is not a big issue.

--Dean

9/24/2005 8:21:59 AM

Joe Audette

Total Posts 18439

View Posts

Re: [Work In Progress] LDAP Authentication

I'm thinking it would be ok to include the dll in the bin folder. If the user running on mono has a newer version it will be in the GAC and that will be used instead of the one in the bin folder won't it?

9/24/2005 8:55:58 AM

Dean Brettle

Total Posts 148

View Posts

Re: [Work In Progress] LDAP Authentication

You're right. Since Novell.Ldap.Directory.dll is strongly named, a more recent version in the GAC would take precedence. Sorry for the confusion.

--Dean

9/25/2005 3:03:56 PM

TJ Fontaine

Total Posts 36

View Posts

Re: [Work In Progress] LDAP Authentication

Edd Dumbill just posted on his blog one of the best tutorials I've seen for setting up LDAP/Samba/Pam wish I would have had this resource long before I started my journey

9/25/2005 4:17:12 PM

Joe Audette

Total Posts 18439

View Posts

Re: [Work In Progress] LDAP Authentication

Yes, I saw that this morning, perfect timing

9/30/2005 11:38:12 AM

TJ Fontaine

Total Posts 36

View Posts

[Patch] LDAP Authentication (Finally)

Sorry, took longer to rip out dead code and manage life at the same time. You can find the patch here. There is still some left over code in LdapManagement.cs that's been commented out that may in some form or another come back to life in a Ldap management module, or in a pure Ldap based backend.

This patch assumes:

You have a properly setup Ldap for user authentication (for instance like this tutorial)
That each desired user have an entry in the UserBaseDN and a mail attribute to be identified from (if more than one entry have the same email the first returned will be used).
A CN attribute exists for use as a display name.
If you specify an AdminEmail and admin@admin.com exists in the DB, the first time the user with AdminEmail logs in the Admin account will be migrated to AdminEmail.

How to use this patch:

Create a new test database (migration to Ldap hasn't been tested, nor reccomended (one could Deploy a new site and then use Ldap auth))
Log in as the default admin@admin.com user
Go to site settings click Use Ldap Auth and specify Ldap Server, Ldap Port, Bind Credentials (in the form "cn=admin,dc=example,dc=org"), User Base DN, and Admin Email. Save.
Logout, and log in as the AdminEmail you specified... Tadah you are the site administrator
Any one else that exists in the UserBaseDN is able to log in.

What you can do with this patch:

Login and authenticate via Ldap
Change User Name, Email* (actually you can't do any of these yet as it isn't supported by MojoPortal yet)

What you can't do with this patch:

Add new users to Ldap database (If a user is added via the memberlist their profile information is used if a user logs in with the specified email)
Delete users from Ldap (If you delete a user from the member list their information will be readded when the log back in)
Change users passwords (This is a bug on my part)

Comments on my terrible coding style welcomed, along with any thoughts, concerns, or ideas of things to change in the patch.

9/30/2005 11:48:40 AM

TJ Fontaine

Total Posts 36

View Posts

Re: [Work In Progress] LDAP Authentication

Also one quick note to add, I've only added the extra pieces for Postgres, though adding mysql/mssql shouldn't be difficult.

In the future depending on how involved any Ldap authentication may be, there may be the addition of an Ldap table to handle attribute mapping, along with the corresponding stored procedures. Though I thought the creation of a table for this revision of Ldap auth to be a bit over the top.

9/30/2005 3:52:23 PM

Joe Audette

Total Posts 18439

View Posts

Re: [Work In Progress] LDAP Authentication

Cool,

I'll try to schedule some time on sunday to try and get the ldap working on my Suse 9.3 machine.

Thanks,

Joe

9/30/2005 4:55:33 PM

Joe Audette

Total Posts 18439

View Posts

Re: [Work In Progress] LDAP Authentication

TJ,

The patch looks like a diff file. Can you make a patch with TortoiseSVN against the latest mojoPortal?
Right click the root folder and choose SVNUpdate then, after the update, right click the root folder and choose TortoiseSVN > Create Patch to create the patch against svn.

Thanks,

Joe

10/1/2005 4:43:44 AM

TJ Fontaine

Total Posts 36

View Posts

Re: [Work In Progress] LDAP Authentication

Apologies the link has been updated as an svnpatch, didn't realize the subtle differences between a standard diff and one from svn

10/1/2005 5:16:24 AM

Joe Audette

Total Posts 18439

View Posts

Re: [Work In Progress] LDAP Authentication

Thanks TJ,

I think the linux svn client can actually work with diff files but Tortoise needs the patch. This one looks good. I'll apply it on a copy of mojoportal and then as soon as I can get the ldap working on my machine I'll give it a try.

I'll post again when I have more to report.

10/1/2005 5:27:46 AM

Joe Audette

Total Posts 18439

View Posts

Re: [Work In Progress] LDAP Authentication

Oops the patch is missing your new files for ldap. You need to right click the new files and choose TortoiseSVN > Add
after that re-create the patch and it should be good. Also can you provide a link to download your Novell.Directory.Ldap.dll I',m sure its going to need that to build.

Thanks!

10/1/2005 5:57:04 AM

TJ Fontaine

Total Posts 36

View Posts

Re: [Work In Progress] LDAP Authentication

heh, ya I noticed that the svn diff missed my ldap files and I already updated the patch, the dll is there now as well

10/1/2005 5:58:15 AM

TJ Fontaine

Total Posts 36

View Posts

Re: [Work In Progress] LDAP Authentication

http://getsweaaa.com/mojoPortal/Novell.Directory.Ldap.dll

is the url

10/1/2005 6:33:01 AM

Joe Audette

Total Posts 18439

View Posts

Re: [Work In Progress] LDAP Authentication

I applied the patch and put the dll in the bin folder but when I try to compile I get this error:

c:\__Projects\Contributors\TJFontaine\mojoportal\Business\bin\Debug\Novell.Directory.Ldap.dll Referenced class 'Novell.Directory.Ldap.LdapAttributeSet' has base class or interface 'AbstractSetSupport' defined in an assembly that is not referenced. You must add a reference to assembly 'Novell.Directory.Ldap, Version=2.1.3.0, Culture=neutral'.

I do have a reference to the assembly so not sure what the problem is, any ideas?

10/1/2005 6:37:41 AM

TJ Fontaine

Total Posts 36

View Posts

Re: [Work In Progress] LDAP Authentication

I got this error when I moved from my old tree into a tree that was just trunk+ldap I believe what I did to resolve the situation was to remove the reference, delete the dll from the debug directory and readd the reference. I'll try locally to see what I can do.

10/1/2005 6:56:06 AM

TJ Fontaine

Total Posts 36

View Posts

Re: [Work In Progress] LDAP Authentication

It's odd, I removed and re-added the dll and still got the error, so I quit vs.net and restarted and it went fine... sorry It's been causing issues

10/1/2005 7:09:46 AM

Joe Audette

Total Posts 18439

View Posts

Re: [Work In Progress] LDAP Authentication

Hey, you're right, I closed VS and re-opened and now it builds.

I'm set with VS now but it may take me awhile to get the ldap setup for testing.

We do need to try an resolve this strange build thing before we start including the Novell dll in svn or it will cause problems for other developers.

Did you compile the dll on linux? Wonder if we can take a snapshot of the source code and add it as a class library project in our solution and build it on windows.

10/1/2005 7:32:23 AM

TJ Fontaine

Total Posts 36

View Posts

Re: [Work In Progress] LDAP Authentication

Yes I compiled the dll with mono 1.1.8.3 on linux, and sure it will build on ms.net there's a build.bat included in the source tree.

10/23/2005 8:45:54 AM

Joe Audette

Total Posts 18439

View Posts

Re: [Work In Progress] LDAP Authentication

Hey TJ I finally got setup to work with your code changes today as you may have read in my blog post.

Your code works per your instructions and looks great!

I am thinking of a few changes:

1. I'm not sure we need to store AdminEmail in the mp_Sites table. I think the admin user should change his email to one that is in LDAP using his profile prior to changing the SiteSettings to use LDAP then we would not need this field because the admin user will be able to login. Actually I'm thinking of adding a field to the mp_Users table named LoginName and use this and password to login instead of email and password. This would be more consistent with how users login to other systems with an LDAP backend and also I think I read that an LDAP user can have more than 1 email address. I've been thinking of changing this even for non LDAP authentication. Maybe I will make that a site setting, whether to use email for the login.

2. I'm thinking I can add a check to prevent the admin from getting locked out by changing the site to use LDAP. We can test binding the BindDN and the current logged in user (Admin) before allowing the change. This would prevent the admin from making a typo in the ldap settings and getting himself locked out.

3. I am concerned about storing the BindPwd in the db in clear text. We need to be able to get that value so one way encryption will not suffice. With 2 way encryption we need a good cross platform way to store the key for decryption. I entered LDAP Administrator credentials for this but maybe thats only needed if we are trying to implement LDAP updates. I will experiment with putting ordinary user credentials there instead of admin, if we can do this it alleviates my concern quite a bit and we may not need encryption. The Administrator credentials are the keys to the kingdom. I can envision a company wanting to setup mojoportal as an extranet authenticating against their internal domain so they don't have to create secondary logins for the web site but we have to make sure we are not exposing secrets of the internal network to the outside world. Even internal users with legit access directly to the db should not have easy access to the LDAP Administrator password. If we can get away with authentication without storing Admin credentials in the db then maybe next we can implement some pages for LDAP administration that require the user to enter the correct credentials to make an update and use SSL to protect that.

I'm just getting started with really looking into this and thinking it through. Let me know your thoughts on the above and I'll post more as I progress.

Great Work! Glad to finally be able to work with it.

Joe

Update: 2:06 PM It doesn't seem to work without the Administrator credentials:

[LdapException: Invalid Credentials]
Novell.Directory.Ldap.LdapResponse.chkResultCode() +30
Novell.Directory.Ldap.LdapConnection.chkResultCode(LdapMessageQueue queue, LdapConstraints cons, LdapResponse response) +147
Novell.Directory.Ldap.LdapConnection.Bind(Int32 version, String dn, SByte[] passwd, LdapConstraints cons) +174
Novell.Directory.Ldap.LdapConnection.Bind(Int32 version, String dn, String passwd, LdapConstraints cons) +175
Novell.Directory.Ldap.LdapConnection.Bind(String dn, String passwd) +20
mojoPortal.Business.LdapManagement.GetConnection(LdapDetails ld, Boolean bind) in c:\__projects\contributors\tjfontaine\mojoportal\business\ldapmanagement.cs:16
mojoPortal.Business.LdapManagement.LdapLogin(LdapDetails ld, String email, String password) in c:\__projects\contributors\tjfontaine\mojoportal\business\ldapmanagement.cs:52
mojoPortal.Business.SiteUser.Login(SiteSettings siteSettings, String Email, String Password) in c:\__projects\contributors\tjfontaine\mojoportal\business\siteuser.cs:512
mojoPortal.Web.Login.AuthenticateUser() in c:\__projects\contributors\tjfontaine\mojoportal\web\secure\login.aspx.cs:117
mojoPortal.Web.Login.lnkSignin_Click(Object sender, EventArgs e) in c:\__projects\contributors\tjfontaine\mojoportal\web\secure\login.aspx.cs:107
System.Web.UI.WebControls.LinkButton.OnClick(EventArgs e) +108
System.Web.UI.WebControls.LinkButton.System.Web.UI.IPostBackEventHandler.RaisePostBackEvent(String eventArgument) +57
System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String eventArgument) +18
System.Web.UI.Page.RaisePostBackEvent(NameValueCollection postData) +138
System.Web.UI.Page.ProcessRequestMain() +1273

Do you think its possible to get this to work without Administrator credentials or should we be looking for ways to securely store them?

10/23/2005 11:15:34 AM

Joe Audette

Total Posts 18439

View Posts

Re: [Work In Progress] LDAP Authentication

I was able after some review of the code to figure out how to make the login work without having the Administrator credentials in the db by changing this line in LdapManagement.LdapLogin
from
LdapConnection conn = GetConnection(ld, true);
to
LdapConnection conn = GetConnection(ld, false);

This is good news I think. I would like to avoid having to figure a secure way to store the Administrator credentials if possible and I think it is possible at this point.

10/25/2005 7:33:22 AM

TJ Fontaine

Total Posts 36

View Posts

Re: [Work In Progress] LDAP Authentication

woo hoo congrats on beating ldap into submission :-)

1: using an alternative field like LoginName would indeed be a preferred solution as it would allow ldap sites to authenticate on virtually any attribute of their schema

2: excellent idea, though of course last resort they should be able to know how to handle the db enough to change it on their own :-)

3: as you found out there is no reason why we can't use a lesser privileged user, it's unfortunate that it didn't work OOTB which was my initial expectation.

I've been thinking about password manipulation for the users, we'll probably want to use something similar to how pam/passwd handles it with passing in the old password to bind to ldap and then changing the password. In fact we could use a similar tactic of passing their ldap password for any profile change, that way we only ever use the user stored in the db to bind to the ldap db at logon time.

If there is anything you need/want me to do don't be afraid to delegate it :-)

10/25/2005 3:41:01 PM

Joe Audette

Total Posts 18439

View Posts

Re: [Work In Progress] LDAP Authentication

Hey TJ,

I have been making some changes and hope to have everything committed for all 3 data layers by the end of the weekend.
The main changes so far are that I have reduced to 3 LDAP site settings, Host Name, Port, Root DN and renamed a couple items. Not that there was anything wrong with your naming scheme, just making it consistent with other things in the project. Specifically, I changed LdapManager to LdapHelper and LdapDetails to LdapSettings. Hope you don't mind

I do have an idea for something I think would be really cool, if you would like to work on it. A set of pages for generic Ldap Administration (separate from user profile) that would use the site Ldap settings but require the user to enter their own ldap credentials to view or update objects in the ldap directory. If it could dynamically adapt to or determine the schema and just show what is there and make it possible to edit/add items it would be an awesome tool. All subject to the user's permissions in Ldap, of course. Since it would be new pages you could start (if you want to) without waiting to get my changes back. What do you think? Is it even possible or would you have to know the schema ahead of time?

Joe

10/26/2005 10:40:32 AM

TJ Fontaine

Total Posts 36

View Posts

Re: [Work In Progress] LDAP Authentication

Hey,

Feel free to change what you want in the code. Also, it dawned on me (from your previous change to the patch) that credentials should be optional, as you can anonymously bind to ldap, and then simply try and bind as the new user for login verification, my mistake for not realizing that from the get go.

As far as implementing a generic page without knowing the schema before hand, it's completely doable. In fact Novell.Directory.Ldap provides a Utilclass namepace that has a SchemaParser object all ready and waiting for use. Unfortunately documentation is sparse, but it appears to be straight forward. I was thinking in tandem with such a module, there would be a module for templates so users could handle new user/entry creation with the defaults/required attributes they want. I'll try and work up some proof of concept code for the first module at the begining of the week.

10/26/2005 2:44:38 PM

Joe Audette

Total Posts 18439

View Posts

Re: [Work In Progress] LDAP Authentication

Excellent! Keep me posted and let me know if you need anything. I should have the initial code in svn this weekend and we can get back in sync.

I really think you could spin off another project with the ASP.NET LDAP Administrator yet keep it so its easy to integrate into mojoPortal too. It doesn't really even need to be a module per se, it can be separate pages. I'm thinking we would have a link to it in site settings but hide the link until they check the Use LDAP setting. After they click save the test code will run to validates the ldap settings as bindable using anonymous before letting them make the change. Then show a link or button to the ldap settings pages where they can manage the directory.

Joe