Calendar
|
May '08 |
|
||||
| Mon | Tue | Wed | Thu | Fri | Sat | Sun |
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 | 31 | |
Tag Cloud
Active Directory AD ADAM Amanda Asterisk Benchmark Blog Catalyst DBIC DBIx-Class Directory Services Disaster Recovery Dojo Encrypted Backups Enterprise Backups Enterprise Directory Fedora Fedora Directory Server Fedora DS IAM Identity Management IDM JavaScript LDAP LDAP Replication LDAP Schema Linux Microsoft Microsoft FUD MirrorMode OID OpenDS OpenLDAP Open Source Oracle Oracle Internet Directory PABX Perl PostgreSQL Quad-Core RDBMS Replication Samba Sendmail Sun Sun Microsystems SunOne Suretec Symas VoIP X.500
Quicksearch
Archives
Powered by
Entries tagged as Active Directory
Suretec RDBMS Oracle Internet Directory Amanda Disaster Recovery Microsoft FUD MirrorMode Identity Management OpenLDAP Symas Sun Sun Microsystems Altix AD Fedora DS DBIC Enterprise Directory Quad-Core Microsoft Oracle IDM Enterprise Backups OID Open Source Sendmail Linux Google SSO eDirectory Catalyst Encrypted Backups DBIx-Class JavaScript O'Reilly PostgreSQL LDAP Schema LDAP Replication Benchmark LDAP Perl Fedora Directory Server Directory Services IAM Samba SunOne ADAM
A good thing for LDAP?
Friday, April 11. 2008
Posted by Gavin Henry
in Open Source, OpenLDAP
at
19:19
| Comments (0)
| Trackbacks (0)
Defined tags for this entry: AD
, ADAM
, Active Directory
, Directory Services
, Enterprise Directory
, IAM
, IDM
, Identity Management
, LDAP
, Linux
, Microsoft
, Open Source
, OpenLDAP
, ADAM, Active Directory, Directory Services, Enterprise Directory, IAM, IDM, Identity Management, LDAP, Linux, Microsoft, Open Source, OpenLDAPSpring 2008 - a UKUUG Conference Review
Thursday, April 3. 2008
I got back last night, after a somewhat hectic Flybe.com flight (long story).
I really enjoyed the conference, my first time speaking at one, bit nervous, but it can only get better
Tuesday:
I really enjoyed the conference, my first time speaking at one, bit nervous, but it can only get better
Tuesday:
Continue reading "Spring 2008 - a UKUUG Conference Review"
Posted by Gavin Henry
in Linux, Open Source, OpenLDAP, Perl, PostgreSQL, Suretec
at
13:37
| Comments (0)
| Trackbacks (0)
Defined tags for this entry: Active Directory, Amanda
, Catalyst
, DBIC
, DBIx-Class
, Directory Services, Disaster Recovery
, Encrypted Backups
, Enterprise Backups
, Enterprise Directory, Fedora Directory Server
, Google
, IAM, IDM, Identity Management, JavaScript
, LDAP, LDAP Replication
, LDAP Schema
, Linux, MirrorMode
, OID
, Open Source, OpenLDAP, Perl
, PostgreSQL
, RDBMS
, Sendmail
, Sun Microsystems
, SunOne
, Suretec
, Amanda, Catalyst, DBIC, DBIx-Class, Directory Services, Disaster Recovery, Encrypted Backups, Enterprise Backups, Enterprise Directory, Fedora Directory Server, Google, IAM, IDM, Identity Management, JavaScript, LDAP, LDAP Replication, LDAP Schema, Linux, MirrorMode, OID, Open Source, OpenLDAP, Perl, PostgreSQL, RDBMS, Sendmail, Sun Microsystems, SunOne, SuretecOracle Internet Directory and 2 Billion Entries?
Thursday, March 27. 2008
I've just finished reading The 2 billion entry directory tree - The scalability of Oracle Internet Directory at very large Directory Information Tree sizes, and thought I'd blog some initial thoughts (I'm sure our partners Symas will have something to say later).
The following is from the 2 Billion User Benchmark (Oracle Internet Directory 10.1.4.0.1) - Technical Whitepaper (PDF) on the Oracle Internet Directory homepage.
So here's the Network kit they used:
Some pretty accessible kit there!
The following is from the 2 Billion User Benchmark (Oracle Internet Directory 10.1.4.0.1) - Technical Whitepaper (PDF) on the Oracle Internet Directory homepage.
So here's the Network kit they used:
Some pretty accessible kit there!
Continue reading "Oracle Internet Directory and 2 Billion Entries?"
Posted by Gavin Henry
in Linux, OpenLDAP
at
09:20
| Comments (0)
| Trackbacks (0)
Defined tags for this entry: AD, Active Directory, Altix
, Benchmark
, IDM, Identity Management, LDAP, Linux, OID, OpenLDAP, Oracle
, Oracle Internet Directory
, PostgreSQL, Quad-Core
, Suretec, Symas
, Active Directory, Altix, Benchmark, IDM, Identity Management, LDAP, Linux, OID, OpenLDAP, Oracle, Oracle Internet Directory, PostgreSQL, Quad-Core, Suretec, SymasOpenLDAP King of the Hill - OpenLDAP Chief Architect Interview
Monday, March 10. 2008
Suretec saw a sneak peak before it was out, but we're glad to say it's unchanged and a cracker!
Have a read:
Want OpenLDAP for your Enterprise? Then contact the UK Leading OpenLDAP Experts.
Suretec®
Have a read:
OpenLDAP is unmatched by any other directory service, proprietary or open source. Of all the others available, the proprietary ones are just hiding their dirty laundry and all of them are just a waste of time and money.
Want OpenLDAP for your Enterprise? Then contact the UK Leading OpenLDAP Experts.
Suretec®
Posted by Suretec
in OpenLDAP
at
12:30
| Comments (0)
| Trackbacks (0)
Defined tags for this entry: AD, ADAM, Active Directory, Directory Services, Enterprise Directory, Fedora DS
, Fedora Directory Server, IAM, IDM, Identity Management, LDAP, LDAP Replication, LDAP Schema, Linux, Microsoft FUD
, OpenLDAP, Oracle Internet Directory, Sun
, SunOne, Suretec, Symas, eDirectory
, ADAM, Active Directory, Directory Services, Enterprise Directory, Fedora DS, Fedora Directory Server, IAM, IDM, Identity Management, LDAP, LDAP Replication, LDAP Schema, Linux, Microsoft FUD, OpenLDAP, Oracle Internet Directory, Sun, SunOne, Suretec, Symas, eDirectoryIn reply to "A common weakness in OpenLDAP"
Tuesday, January 29. 2008
This was posted in reply to our post A Common Weakness in all Identity Management Products", but not OpenLDAP:
Hmmm, the Symas paper we referenced does indeed discuss the cost to maintain OpenLDAP on pages 6 and 7 of the paper
It's more to do with the fact both Suretec and Symas aren't allowed to say. Have a look at Key Relationships or again, contact either Suretec or Symas.
It is interesting to see how a thread on how identity provisioning tools and their lack of true interoperability with Active Directory gets twisted into a discussion on the merits of OpenLDAP. What is interesting is that the comparison is solely technical and doesn't provide any rationale related to how much it would cost to maintain OpenLDAP vs ADAM[?].
Hmmm, the Symas paper we referenced does indeed discuss the cost to maintain OpenLDAP on pages 6 and 7 of the paper
You will also notice mention of one and only one Fortune enterprise that uses it as their primary directory service. Of course, the mentioned company is in the consulting business so this isn't surprising. Maybe the mention of a bank or retailer in the Fortune ranks is in order. I suspect the economics nor the customer base simply aren't their...
It's more to do with the fact both Suretec and Symas aren't allowed to say. Have a look at Key Relationships or again, contact either Suretec or Symas.
Posted by Suretec
in OpenLDAP, Suretec
at
12:53
| Comments (0)
| Trackbacks (0)
Defined tags for this entry: AD, ADAM, Active Directory, Directory Services, Enterprise Directory, IAM, Identity Management, LDAP, Linux, Microsoft FUD, OpenLDAP, Suretec, Symas
, ADAM, Active Directory, Directory Services, Enterprise Directory, IAM, Identity Management, LDAP, Linux, Microsoft FUD, OpenLDAP, Suretec, Symas"A Common Weakness in all Identity Management Products", but not OpenLDAP
Tuesday, January 22. 2008
A few comments on A Common Weakness in all Identity Management Products:
I would disagree. OpenLDAP is right up there, in fact most enterprises don't use AD[?] for true Directory requirements. Speak to Suretec and Symas for more information.
I would urge the author to read the ADAM[?] vs. LDAP[?] White Paper, an evaluation of Microsoft's ADAM to LDAP, written by our friends and partners Symas
Consider for a moment, how many Fortune enterprises have Active Directory in a production environment. Out of the Fortune 500, Sun is the only hold out. You would think that if Active Directory were so pervasively implemented that software vendors would want to deeply integrate with it, but nothing could be further from the truth.
I would disagree. OpenLDAP is right up there, in fact most enterprises don't use AD[?] for true Directory requirements. Speak to Suretec and Symas for more information.
I would urge the author to read the ADAM[?] vs. LDAP[?] White Paper, an evaluation of Microsoft's ADAM to LDAP, written by our friends and partners Symas
Continue reading ""A Common Weakness in all Identity Management Products", but not OpenLDAP"
Posted by Gavin Henry
in OpenLDAP, Suretec
at
14:05
| Comments (0)
| Trackback (1)
Defined tags for this entry: AD, ADAM, Active Directory, Directory Services, Enterprise Directory, IAM, Identity Management, LDAP, Linux, Microsoft FUD, OID, OpenLDAP, Oracle Internet Directory, Sun, Sun Microsystems, Suretec, Symas
, ADAM, Active Directory, Directory Services, Enterprise Directory, IAM, Identity Management, LDAP, Linux, Microsoft FUD, OID, OpenLDAP, Oracle Internet Directory, Sun, Sun Microsystems, Suretec, Symas"At best AD is 4 times slower than OpenLDAP"
Thursday, December 6. 2007
Suretec partners Symas have released the final results of benchmarking ADAM[?] and AD[?] versus OpenLDAP at AD and ADAM Performance: UPDATE
The result are open, so feel free to independently verify (you will need an AMD Celestica A8440 with four Opteron 875s (dual 2.2GHz cores) and 16GB DDR333 RAM though ).
Punchline: at 5,000,000 (5M) entries, OpenLDAP 2.4.6+ delivered 20,179 authentications a second, ADAM delivered 5,424 and AD did 216. The 1,000,000 (1M) entry runs were 23,273 for OpenLDAP, 5,738 for ADAM, and 4,662 for AD.
The result are open, so feel free to independently verify (you will need an AMD Celestica A8440 with four Opteron 875s (dual 2.2GHz cores) and 16GB DDR333 RAM though
).Microsoft hopes LDAP will wither due to a shortage of competitive enterprise features
Tuesday, December 4. 2007
Dear, dear me...In Centeris opens Active Directory to open source:
So,
Sorely mistaken.
Another hook into Microsoft technology. What is wrong with pam and nss ldap[?]....Oh, it's Open Source of course.
What about LDAP[?], the Internet directory standard, I asked.
“We looked at lots of technologies, but first we listened to our enterprise customers. They want to leverage technology in place, and Active Directory has a powerful policy engine. LDAP doesn’t have that. We don’t take a stand. We just go where the customers are.”
That, however, is the other side of the coin here. Microsoft is allowing integration with Active Directory, but over time it hopes LDAP will wither due to a shortage of competitive enterprise features.
So,
[Microsoft] hopes LDAP will wither due to a shortage of competitive enterprise features.
Sorely mistaken.
Another hook into Microsoft technology. What is wrong with pam and nss ldap[?]....Oh, it's Open Source of course.
Posted by Gavin Henry
in OpenLDAP, Suretec
at
17:35
| Comments (0)
| Trackback (1)
Defined tags for this entry: Active Directory, Directory Services, Linux, Microsoft FUD, OpenLDAP, Suretec, Symas
, Directory Services, Linux, Microsoft FUD, OpenLDAP, Suretec, SymasBad LDAP coding, bad Application, but....maybe the LDAP Implementation?
Saturday, December 1. 2007
It is true that Poorly written LDAP[?] code can really affect your Portal, Suretec have seen it a few times:
A programmer who hadn't had much exposure to LDAP decided it best to do a base level search, for example, usingldapsearch:
he retrieved *everything*, then did all the searching/filtering etc. locally in the client! What's the point of a Directory Server!?!
Our partners Symas have also talked about similar encounters, mainly with Sendmail.
It all comes down to the level of LDAP understanding a programmer has.
Or could it actually be the Directory Server implementation, namely Oracle Internet Directory (OID)?
I know OpenLDAP wouldn't slow an app down like this, because it's very fast..very very fast
A programmer who hadn't had much exposure to LDAP decided it best to do a base level search, for example, using
CODE:
ldapsearch -x -b 'dc=suretecsystems,dc=com' '(objectclass=*)' -H ldap[?]://127.0.0.1
he retrieved *everything*, then did all the searching/filtering etc. locally in the client! What's the point of a Directory Server!?!
Our partners Symas have also talked about similar encounters, mainly with Sendmail.
It all comes down to the level of LDAP understanding a programmer has.
Or could it actually be the Directory Server implementation, namely Oracle Internet Directory (OID)?
I know OpenLDAP wouldn't slow an app down like this, because it's very fast..very very fast
Posted by Gavin Henry
in OpenLDAP, Suretec
at
10:38
| Comments (5)
| Trackback (1)
Defined tags for this entry: ADAM, Active Directory, Directory Services, IAM, Identity Management, LDAP, Linux, OID, OpenLDAP, Oracle, Oracle Internet Directory, Perl, PostgreSQL, SSO
, Sendmail, Suretec, Symas
, Active Directory, Directory Services, IAM, Identity Management, LDAP, Linux, OID, OpenLDAP, Oracle, Oracle Internet Directory, Perl, PostgreSQL, SSO, Sendmail, Suretec, SymasOpenLDAP and LDAP Roundup - 29th Nov 2007
Thursday, November 29. 2007
Quite a few interesting articles and blog posts today.
Whenever I see a few good ones, I'll do one of these roundup posts.
Whenever I see a few good ones, I'll do one of these roundup posts.
- The Linux Networking Cookbook is out, which includes a section on OpenLDAP.
- Andy writes about his OpenLDAP Replication Design thoughts; I'll comment on this later.
- Someone really likes GOsa, which is a very good LDAP[?] web admin tool. We like it too.
- Peter Judge doesn't seem to understand the difference between a Directory Server and Active Directory. We blogged about this common mistake yesterday.
- Our partners Symas, keep us updated on the unfortunate resignation of Neil Wilson in his An Open Letter to the OpenDS Community and to Sun Microsystems post. We share the same thoughts as the comments in the post, but I'll add that some companies just don't understand how FLOSS[?] works or how a community works.