The subnet calculator helps you design networks by taking an IP address and network mask and returning information such as network, broadcast address, and host range.
One of a set of tools we're offering as a way of saying thank you for being a part of the community.
Solved
I need a two-way link to eDirectory through ASP
Posted on 2006-07-20
Some background:
I am writing a web interface (using ASP/AJAX) to both view and manage employee account information. We chose eDirectory as the database. The Web interface will also integrate a help-ticket system (login info), web Mail account information (email address/login info) and the Novell network account info.
Everything is done except for the eDirectory link.
I downloaded the ODBC driver for eDirectory on recommendation from someone at a BrainShare; they told me that basically you could use just about any valid SQL statement to access eDirectory. I thought it would be a breeze but I guess I am missing something.
What I need to be able to do:
...is read and write from and to eDirectory using ADO, DAO or ODBC (or some other method ASP can use that (preferably) involves SQL).
What is happening:
When I run any kind of SQL statement (i.e. "SELECT * WHERE name = 'blah'") using the ODBC interface the web server (that is running the ASP) goes to 100% CPU usage until the ASP script run length expires and the script times out. It locks on the SQL execution statement.
When I link anything other than the most basic eDirectory table (i.e. when I link the printers list or employee list) in Microsoft Access I get seemingly infinite results; i.e. the table just keeps repeating and repeating with slight differences of the same records yet they appear in access as new records, and you can page-down for nearly an hour until Access finally crashes.
I am writing a web interface (using ASP/AJAX) to both view and manage employee account information. We chose eDirectory as the database. The Web interface will also integrate a help-ticket system (login info), web Mail account information (email address/login info) and the Novell network account info.
Everything is done except for the eDirectory link.
I downloaded the ODBC driver for eDirectory on recommendation from someone at a BrainShare; they told me that basically you could use just about any valid SQL statement to access eDirectory. I thought it would be a breeze but I guess I am missing something.
What I need to be able to do:
...is read and write from and to eDirectory using ADO, DAO or ODBC (or some other method ASP can use that (preferably) involves SQL).
What is happening:
When I run any kind of SQL statement (i.e. "SELECT * WHERE name = 'blah'") using the ODBC interface the web server (that is running the ASP) goes to 100% CPU usage until the ASP script run length expires and the script times out. It locks on the SQL execution statement.
When I link anything other than the most basic eDirectory table (i.e. when I link the printers list or employee list) in Microsoft Access I get seemingly infinite results; i.e. the table just keeps repeating and repeating with slight differences of the same records yet they appear in access as new records, and you can page-down for nearly an hour until Access finally crashes.
[X]
Welcome to Experts Exchange
Add your voice to the tech community where 5M+ people just like you are talking about what matters.
- Help others & share knowledge
- Earn cash & points
- Learn & ask questions
-
6
4-
4
- +1
15 Comments
I've done some eDirectory programmatic retrieval and manipulation, but I was using Perl and a direct API, not the ODBC connector.
I'd make sure that the credentials used to authenticate to eDirectory have sufficient privileges to access the data you're looking for. Also, understand that some eDirectory Attributes *cannot* be Read. They can only be Compared. Passwords are an example of this.
Your project sounds, to some extent, like re-inventing Novell Identity Manager, especially the Workflow Provisioning module.
I'd make sure that the credentials used to authenticate to eDirectory have sufficient privileges to access the data you're looking for. Also, understand that some eDirectory Attributes *cannot* be Read. They can only be Compared. Passwords are an example of this.
Your project sounds, to some extent, like re-inventing Novell Identity Manager, especially the Workflow Provisioning module.
PsiCop, is the API you used workable in ASP?
I was reading about Novell Identity Manager, but on Novell's site (http://www.novell.com/products/identitymanager/howtobuy.html), one instance license lists for $75,000.00, more than I make in 2 years. Not to mention the $25 per user, which would add another $30,000.00, so I have about 3 years to come up with something else and still come out ahead if those prices are right, and that doesn't even enclude provisioning. That is just insane. It took me about 2 weeks to write my own web interface and it does the job fine, integrates better and cost more than a hundred times less.
What's more is basically I am done, it works with an access database now, I would just like to integrate it with eDirectory.
It looked like the eDirectory ODBC was the way to go, it just is not working for me for some reason.
As for credentials, I authenticate as admin with full privileges and it does the same thing :(
I was reading about Novell Identity Manager, but on Novell's site (http://www.novell.com/products/identitymanager/howtobuy.html), one instance license lists for $75,000.00, more than I make in 2 years. Not to mention the $25 per user, which would add another $30,000.00, so I have about 3 years to come up with something else and still come out ahead if those prices are right, and that doesn't even enclude provisioning. That is just insane. It took me about 2 weeks to write my own web interface and it does the job fine, integrates better and cost more than a hundred times less.
What's more is basically I am done, it works with an access database now, I would just like to integrate it with eDirectory.
It looked like the eDirectory ODBC was the way to go, it just is not working for me for some reason.
As for credentials, I authenticate as admin with full privileges and it does the same thing :(
I have no idea if the API is available via ASP. I really don't know much about ASP. I do know that Novell publishes an ActiveX SDK (see http://developer.novell.com/wiki/index.php/Category:Novell_Developer_Kit) and that you can use the ActiveX APIs from ASP. With a quick search I found two DeveloperNet articles that seem relevant: http://developer.novell.com/wiki/index.php/TID101916_%28aspactx%29_Sample_code_demonstrating_Novell%27s_ActiveX_in_Microsoft%27s_ASP and http://developer.novell.com/wiki/index.php/TID102028_%28asptree%29_ASP_sample_code_which_demonstrates_how_to_retrieve_objects_from_DS_tree_in_ASP_page_using_ActiveX
As for IDM, I don't think you have the pricing right. The $75K license sounds like the cost of the IDM Workflow Provisioning module. It's about the only Novell product that's licensed per-instance. Practically every other product they sell is licensed per-user, and last time I checked, that included Identity Manager itself. Before you go tossing the baby out with the bathwater, I'd suggest getting ahold of a Novell sales rep and getting an actual pricing quote from them. I really do think you're misreading the info.
While it might be a lot cheaper, do you really want to trust business-critical functions to Access? There's no replication, no data integrity checking inherent in the DB engine, it's "security" is laughably crude, it has no effective audit trail... the list of reasons to *not* use it goes on. Using Access to drive changes to eDirectory is like using a blind, lame mule as the lead for a racing-trained thoroughbred.
No matter what you use, have you tried turning on the DSTRACE functions on the eDirectory server and watching what is happening on that end? I dunno what platform you have hosting eDirectory (since you have a choice, unlike, say, AD), so until I know that its difficult to give you precise instructions on what to do to capture the traces.
As for IDM, I don't think you have the pricing right. The $75K license sounds like the cost of the IDM Workflow Provisioning module. It's about the only Novell product that's licensed per-instance. Practically every other product they sell is licensed per-user, and last time I checked, that included Identity Manager itself. Before you go tossing the baby out with the bathwater, I'd suggest getting ahold of a Novell sales rep and getting an actual pricing quote from them. I really do think you're misreading the info.
While it might be a lot cheaper, do you really want to trust business-critical functions to Access? There's no replication, no data integrity checking inherent in the DB engine, it's "security" is laughably crude, it has no effective audit trail... the list of reasons to *not* use it goes on. Using Access to drive changes to eDirectory is like using a blind, lame mule as the lead for a racing-trained thoroughbred.
No matter what you use, have you tried turning on the DSTRACE functions on the eDirectory server and watching what is happening on that end? I dunno what platform you have hosting eDirectory (since you have a choice, unlike, say, AD), so until I know that its difficult to give you precise instructions on what to do to capture the traces.
I read into the ActiveX APIs and they are way more in-depth than I'd like to learn for this project, especially since I am so close to using plain SQL with ODBC. It seems really odd that eDirectory only has this one ODBC driver for a standard SQL interface, is there anything else?
If not deleting records that often, access never really fails, access is also like modeling clay; so much easier to sculpt with, so many more tools available, etc, etc. but not the material you'd choose to build your retail product I know. I love enterprise SQL based databases but access gets smaller jobs done faster. Nobody needs integrity checking if all the records are "asdf" anyways =). Sculptors dont need to sketch with the same marble block they are planning to finish with is what I mean.
I am planning on using eDirectory exclusively for this project, we already store all the data we need in eDirectory. I have no workable SQL interface into eDirectory right now though, I just plopped together an access database to hold test data. Now I am done with access here, I want eDirectory, that is my whole problem.
We are hosting eDirectory on a Netware 6.5 server... I dont know anything about DSTRACE, I'll go read about it...
If not deleting records that often, access never really fails, access is also like modeling clay; so much easier to sculpt with, so many more tools available, etc, etc. but not the material you'd choose to build your retail product I know. I love enterprise SQL based databases but access gets smaller jobs done faster. Nobody needs integrity checking if all the records are "asdf" anyways =). Sculptors dont need to sketch with the same marble block they are planning to finish with is what I mean.
I am planning on using eDirectory exclusively for this project, we already store all the data we need in eDirectory. I have no workable SQL interface into eDirectory right now though, I just plopped together an access database to hold test data. Now I am done with access here, I want eDirectory, that is my whole problem.
We are hosting eDirectory on a Netware 6.5 server... I dont know anything about DSTRACE, I'll go read about it...
For the DSTRACE info, check out my AppNote from May 10th on accessing eDirectory from Perl (see http://www.novell.com/coolsolutions/appnote/bydate.html). You're not using Perl, but the debugging info on Page 18 is relevant to your needs.
I really don't know much more about ODBC than I do about ASP. My development background was in systems, not databases, and aside from some modest shell scripting and Perl coding now and again. I really haven't coded in years. Anyway, I can't offer any cogent comment on the state of the ODBC driver for eDirectory, or alternatives. You might try the DeveloperNet Forums. Some of the Novell Developers hang out there, and they will respond to questions posed in the forums. Sign-up is free, here's the link for DeveloperNet --> http://developer.novell.com/wiki/index.php/Developer_Home
I really don't know much more about ODBC than I do about ASP. My development background was in systems, not databases, and aside from some modest shell scripting and Perl coding now and again. I really haven't coded in years. Anyway, I can't offer any cogent comment on the state of the ODBC driver for eDirectory, or alternatives. You might try the DeveloperNet Forums. Some of the Novell Developers hang out there, and they will respond to questions posed in the forums. Sign-up is free, here's the link for DeveloperNet --> http://developer.novell.com/wiki/index.php/Developer_Home
Thank you very much for your direction and suggestions PsiCop, I will try them. Do you think this sort of question is a dead end here (EE)?
I dunno if it's a dead end here. I doubt you'll find anyone on EE with the specific coding experience I suspect is needed to help you, but I may be wrong. I have similar experience, just not with ASP or the other tools you're using. I think you're more likely to find the help you need on the Novell DeveloperNet Forums, just because the people there do work with all the tools you're working with.
Sure, you can use valid SQL statements to access eDirectory via the ODBC interface, but, at the risk of being rude (apologies in advance) you're treating it like it's a Jet database or something.
Firstly, it's not that kind of database structure - it's not relational, it doesn't have "tables" - it's its own kind of database structure with its own schema, and uses dynamic inheritance, which might explain why trying to use a table view of something in MSAccess might seem to give infinite results. You have to watch how eDirectory objects get mapped to the "table" structure so you don't end up with that kind of thing happening.
There are specific SQL statments that can be used, too. They're pretty-well spelled out in the documentation for the ODBC driver, so if you stick with what's in the docs you should be OK. The ODBC interface was initially meant just for reporting/lookup but does have a write function now, too.
I suggest this is the best place to start: http://developer.novell.com/wiki/index.php/Develop_to_eDirectory
You may want to switch to something better for directory access/update than ODBC, one of the more-native access methods like SOAP or NDAP.
Firstly, it's not that kind of database structure - it's not relational, it doesn't have "tables" - it's its own kind of database structure with its own schema, and uses dynamic inheritance, which might explain why trying to use a table view of something in MSAccess might seem to give infinite results. You have to watch how eDirectory objects get mapped to the "table" structure so you don't end up with that kind of thing happening.
There are specific SQL statments that can be used, too. They're pretty-well spelled out in the documentation for the ODBC driver, so if you stick with what's in the docs you should be OK. The ODBC interface was initially meant just for reporting/lookup but does have a write function now, too.
I suggest this is the best place to start: http://developer.novell.com/wiki/index.php/Develop_to_eDirectory
You may want to switch to something better for directory access/update than ODBC, one of the more-native access methods like SOAP or NDAP.
Check this walk-through by Michel Bluteau
http://www.novell.com/coolsolutions/appnote/14730.html
http://www.novell.com/coolsolutions/appnote/14730.html
ShineOn, not rude at all, I am new to Novell so I do not understand the eDirectory structure, thanks for the information. Do you have any good links to get me started with SOAP or NDAP? I am not familiar with either.
All I really want to be able to do is:
(at least) query the login and query/update the pass of existing novell accounts.
(and hopefully) create new/remove old novell accounts.
I was told this was possible (and a snap) with ODBC, is this incorrect? If it's possible, unless there is some reason it's a bad idea, this would require the least programming for me, as I would just need to change the connection string of an ADO connection to use eDirectory instead of an SQL database.
(at least) query the login and query/update the pass of existing novell accounts.
(and hopefully) create new/remove old novell accounts.
I was told this was possible (and a snap) with ODBC, is this incorrect? If it's possible, unless there is some reason it's a bad idea, this would require the least programming for me, as I would just need to change the connection string of an ADO connection to use eDirectory instead of an SQL database.
query the login - if that means query the user object, yes.
query/update the pass - if that means change the password, maybe. If that means look up the password, no way - not possible unless you're only using "simple" passwords and even then you'd need the encryption key pair 'cause it's not stored "clear text."
create new/remove old eDirectory accounts - don't know.
In any case, Administrative functions like change password, add user, delete user require authentication to eDirectory with appropriate rights. I don't know if the ODBC interface will log in your IIS service so ASP/ADO can have an authenticated, logged-in connection. That may depend on how you define the data source, I suppose. I do know there are issues with ASP and eDirectory authentication that should be considered security concerns, primarily that ASP, once logged-in, allows any other user the same rights, since it only logs in once per IIS instance, not once per user connection. See this article: http://support.novell.com/techcenter/articles/ana20010907.html.
That said, I don't know that ODBC is necessarily the way to go anyway; I'd think maybe ActiveX controls or SOAP or LDAP or NDAP would be preferable to ODBC, especially when coding ASP, considering the security implications. I'd think ASP/ADO/ODBC would only use the one ODBC instance for everyone, so ODBC login would provide the same potential security hole.
query/update the pass - if that means change the password, maybe. If that means look up the password, no way - not possible unless you're only using "simple" passwords and even then you'd need the encryption key pair 'cause it's not stored "clear text."
create new/remove old eDirectory accounts - don't know.
In any case, Administrative functions like change password, add user, delete user require authentication to eDirectory with appropriate rights. I don't know if the ODBC interface will log in your IIS service so ASP/ADO can have an authenticated, logged-in connection. That may depend on how you define the data source, I suppose. I do know there are issues with ASP and eDirectory authentication that should be considered security concerns, primarily that ASP, once logged-in, allows any other user the same rights, since it only logs in once per IIS instance, not once per user connection. See this article: http://support.novell.com/techcenter/articles/ana20010907.html.
That said, I don't know that ODBC is necessarily the way to go anyway; I'd think maybe ActiveX controls or SOAP or LDAP or NDAP would be preferable to ODBC, especially when coding ASP, considering the security implications. I'd think ASP/ADO/ODBC would only use the one ODBC instance for everyone, so ODBC login would provide the same potential security hole.
Regarding IDM licensing, the basic IDM 3.0 engine is priced at, like, $25US/user. Period. And that's retail - a reseller can do better or they're not worth buying from.
Note that doesn't include upgrade protectio/maintenance, which is a good thing, generally, and depending on your volume agreement may be required. That's $6.30/user for 1 year, $11/user for 2 years, and $16/user for 3 years.
The current VLA doc says:
Snippet/
Novell Identity Manager 3 includes integration modules for several common customer systems including: Novell eDirectory, Microsoft Active Directory, Microsoft Windows NT, LDAP v3Directories, Novell GroupWise, Microsoft Exchange, and Lotus Notes. Novell Identity Manager 3 also includes Designer for Novell Identity Manager 3, a powerful administration tool that dramatically simplifies configuration and deployment.
/Snippet
If you need additional integration modules, those are priced at between $5 and $10 US per user.
The $75,000 price tag is if you want to do a "per instance" license, which only makes sense if you've got thousands of users.
You don't need per-user licensing on top of "per instance" licensing.
Note that doesn't include upgrade protectio/maintenance, which is a good thing, generally, and depending on your volume agreement may be required. That's $6.30/user for 1 year, $11/user for 2 years, and $16/user for 3 years.
The current VLA doc says:
Snippet/
Novell Identity Manager 3 includes integration modules for several common customer systems including: Novell eDirectory, Microsoft Active Directory, Microsoft Windows NT, LDAP v3Directories, Novell GroupWise, Microsoft Exchange, and Lotus Notes. Novell Identity Manager 3 also includes Designer for Novell Identity Manager 3, a powerful administration tool that dramatically simplifies configuration and deployment.
/Snippet
If you need additional integration modules, those are priced at between $5 and $10 US per user.
The $75,000 price tag is if you want to do a "per instance" license, which only makes sense if you've got thousands of users.
You don't need per-user licensing on top of "per instance" licensing.
Thanks guys, I can see from your comment that ODBC is unfortunately not the simpler way to go. I could authenticate once with ASP and then re-authenticate (psudo) using IIS session variables by looking up credentials once I had access to eDirectory for each connection, which would plug the security "hole", but it sounds like the ODBC connector is perhaps too immature or something; everyone is stearing me away from it. I will research the ActiveX SDK that PsiCop mentioned above and the other alternatives like LDAP/NDAP/SOAP.
Thank you guys for your research and help.
Thank you guys for your research and help.
Featured Post
Ready to improve network connectivity? Watch this webinar to learn how SD-WANs and a one-click instant connect tool can boost provisions, deployment, and management of your cloud connection.
Question has a verified solution.
If you are experiencing a similar issue, please ask a related question
When trying to connect from SSMS v17.x to a SQL Server Integration Services 2016 instance or previous version, you get the error “Connecting to the Integration Services service on the computer failed with the following error: 'The specified service …
If you are a mobile app developer and especially develop hybrid mobile apps then these 4 mistakes you must avoid for hybrid app development to be the more genuine app developer.
Sometimes it takes a new vantage point, apart from our everyday security practices, to truly see our Active Directory (AD) vulnerabilities. We get used to implementing the same techniques and checking the same areas for a breach. This pattern can re…
In response to a need for security and privacy, and to continue fostering an environment members can turn to for support, solutions, and education, Experts Exchange has created anonymous question capabilities. This new feature is available to our Pr…
Suggested Courses
Course of the Month7 days, 13 hours left to enroll
715 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.