<article>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#article09_06_04_1911206</id>
	<title>Directory Service Implementation From Scratch?</title>
	<author>timothy</author>
	<datestamp>1244143320000</datestamp>
	<htmltext>An anonymous reader writes <i>"I work at a small but growing startup company.  Currently, our directory and authentication information is scattered across many systems and wikis, and is becoming increasingly difficult to manage.  We are looking at centralizing this information in a directory service to minimize administrative overhead as we continue to grow.  The service must support basic directory searches, as well as user authentication for Linux and Windows hosts.  Although we are primarily a Linux shop, there are a handful of Windows systems that will be on a Windows Active Directory domain.  Most directory servers seem to support integration with other directory servers, however it seems like it may be easiest to just use Active Directory for everything.  Are there any pitfalls with this approach?  If you had the chance to redesign your enterprise directory service without regard for legacy services, how would you do it?"</i></htmltext>
<tokenext>An anonymous reader writes " I work at a small but growing startup company .
Currently , our directory and authentication information is scattered across many systems and wikis , and is becoming increasingly difficult to manage .
We are looking at centralizing this information in a directory service to minimize administrative overhead as we continue to grow .
The service must support basic directory searches , as well as user authentication for Linux and Windows hosts .
Although we are primarily a Linux shop , there are a handful of Windows systems that will be on a Windows Active Directory domain .
Most directory servers seem to support integration with other directory servers , however it seems like it may be easiest to just use Active Directory for everything .
Are there any pitfalls with this approach ?
If you had the chance to redesign your enterprise directory service without regard for legacy services , how would you do it ?
"</tokentext>
<sentencetext>An anonymous reader writes "I work at a small but growing startup company.
Currently, our directory and authentication information is scattered across many systems and wikis, and is becoming increasingly difficult to manage.
We are looking at centralizing this information in a directory service to minimize administrative overhead as we continue to grow.
The service must support basic directory searches, as well as user authentication for Linux and Windows hosts.
Although we are primarily a Linux shop, there are a handful of Windows systems that will be on a Windows Active Directory domain.
Most directory servers seem to support integration with other directory servers, however it seems like it may be easiest to just use Active Directory for everything.
Are there any pitfalls with this approach?
If you had the chance to redesign your enterprise directory service without regard for legacy services, how would you do it?
"</sentencetext>
</article>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28219153</id>
	<title>OpenLDAP for the masses</title>
	<author>Anonymous</author>
	<datestamp>1244145360000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I have been running 2 heavily used (20k users) OpenLDAP implementations for about 5 years now. Runs great.</p></htmltext>
<tokenext>I have been running 2 heavily used ( 20k users ) OpenLDAP implementations for about 5 years now .
Runs great .</tokentext>
<sentencetext>I have been running 2 heavily used (20k users) OpenLDAP implementations for about 5 years now.
Runs great.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214249</id>
	<title>Re:Just go with AD</title>
	<author>dpilot</author>
	<datestamp>1244106180000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>I've looked into LDAP/Kerberos authentication for my home LAN several times, and basically given up every time.  There appears to be a software mix that will do the job, but each piece needs to be configured *just so* in order to work with all of the others.  Furthermore, there appear to be a few people out there who really know their stuff, and to them I'll bet this is all easy.</p><p>But it appears that those people all work for companies that sell Directory Server services.  They're quite willing to be helpful on specific questions, but the overall integration is still not well documented, from what I can see.  As near as I can tell, it's like the Bad Old Unix days, when everyone wanted to be The Solution - for a price.  I haven't really looked at the RedHat Directory server or similar products, wishing to use the pieces, and wishing for integration documentation.</p><p>Why this on a home LAN?  For some odd reason, I've tried to run my LAN on industrial-strength software - BIND, ISC DHCP, etc.  I'm used to single-sign-in at work, and would really like it at home, given that $HOME is shared over NFSv4.  I also usually am too busy doing other things, which is another reason why there's been no progress in years.</p><p>Maybe an integrated OSS Directory Server will make it into my house, but there's no way I'm footing the bill it would take to add AD, here.</p></htmltext>
<tokenext>I 've looked into LDAP/Kerberos authentication for my home LAN several times , and basically given up every time .
There appears to be a software mix that will do the job , but each piece needs to be configured * just so * in order to work with all of the others .
Furthermore , there appear to be a few people out there who really know their stuff , and to them I 'll bet this is all easy.But it appears that those people all work for companies that sell Directory Server services .
They 're quite willing to be helpful on specific questions , but the overall integration is still not well documented , from what I can see .
As near as I can tell , it 's like the Bad Old Unix days , when everyone wanted to be The Solution - for a price .
I have n't really looked at the RedHat Directory server or similar products , wishing to use the pieces , and wishing for integration documentation.Why this on a home LAN ?
For some odd reason , I 've tried to run my LAN on industrial-strength software - BIND , ISC DHCP , etc .
I 'm used to single-sign-in at work , and would really like it at home , given that $ HOME is shared over NFSv4 .
I also usually am too busy doing other things , which is another reason why there 's been no progress in years.Maybe an integrated OSS Directory Server will make it into my house , but there 's no way I 'm footing the bill it would take to add AD , here .</tokentext>
<sentencetext>I've looked into LDAP/Kerberos authentication for my home LAN several times, and basically given up every time.
There appears to be a software mix that will do the job, but each piece needs to be configured *just so* in order to work with all of the others.
Furthermore, there appear to be a few people out there who really know their stuff, and to them I'll bet this is all easy.But it appears that those people all work for companies that sell Directory Server services.
They're quite willing to be helpful on specific questions, but the overall integration is still not well documented, from what I can see.
As near as I can tell, it's like the Bad Old Unix days, when everyone wanted to be The Solution - for a price.
I haven't really looked at the RedHat Directory server or similar products, wishing to use the pieces, and wishing for integration documentation.Why this on a home LAN?
For some odd reason, I've tried to run my LAN on industrial-strength software - BIND, ISC DHCP, etc.
I'm used to single-sign-in at work, and would really like it at home, given that $HOME is shared over NFSv4.
I also usually am too busy doing other things, which is another reason why there's been no progress in years.Maybe an integrated OSS Directory Server will make it into my house, but there's no way I'm footing the bill it would take to add AD, here.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213757</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213879</id>
	<title>quit</title>
	<author>docbrody</author>
	<datestamp>1244147880000</datestamp>
	<modclass>Flamebait</modclass>
	<modscore>0</modscore>
	<htmltext>quit your job and let someone else deal with it</htmltext>
<tokenext>quit your job and let someone else deal with it</tokentext>
<sentencetext>quit your job and let someone else deal with it</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214085</id>
	<title>389-ds</title>
	<author>aichainz</author>
	<datestamp>1244148660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>aka fedora-ds has been very flexible and is able to provide SSO for many applications, from apps that support pam, to tacacs, apache, cvs etc.  admittedly i havent gone so far as to auth a windows pc against it, but that doesnt mean it's necessarily a good idea to use AD and have linux auth against that.

multi-master replication in 389 works great, and we even have a 3rd master who is on the other side of a wan-link.</htmltext>
<tokenext>aka fedora-ds has been very flexible and is able to provide SSO for many applications , from apps that support pam , to tacacs , apache , cvs etc .
admittedly i havent gone so far as to auth a windows pc against it , but that doesnt mean it 's necessarily a good idea to use AD and have linux auth against that .
multi-master replication in 389 works great , and we even have a 3rd master who is on the other side of a wan-link .</tokentext>
<sentencetext>aka fedora-ds has been very flexible and is able to provide SSO for many applications, from apps that support pam, to tacacs, apache, cvs etc.
admittedly i havent gone so far as to auth a windows pc against it, but that doesnt mean it's necessarily a good idea to use AD and have linux auth against that.
multi-master replication in 389 works great, and we even have a 3rd master who is on the other side of a wan-link.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213741</id>
	<title>AD -- de facto standard</title>
	<author>Anonymous</author>
	<datestamp>1244147340000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Depending on your company's skillset, having AD as your core directory may be your best choice.  The advantage is that its one point of access, one set of usernames and passwords for users, and so on.</p><p>AD in general also has a lot of management tools and knowledge available.</p><p>Of course, this isn't to say that OpenLDAP or other directory solutions are bad.  Its just that in general, most vendors will bend over backwards to give Active Directory support for their products.</p></htmltext>
<tokenext>Depending on your company 's skillset , having AD as your core directory may be your best choice .
The advantage is that its one point of access , one set of usernames and passwords for users , and so on.AD in general also has a lot of management tools and knowledge available.Of course , this is n't to say that OpenLDAP or other directory solutions are bad .
Its just that in general , most vendors will bend over backwards to give Active Directory support for their products .</tokentext>
<sentencetext>Depending on your company's skillset, having AD as your core directory may be your best choice.
The advantage is that its one point of access, one set of usernames and passwords for users, and so on.AD in general also has a lot of management tools and knowledge available.Of course, this isn't to say that OpenLDAP or other directory solutions are bad.
Its just that in general, most vendors will bend over backwards to give Active Directory support for their products.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214801</id>
	<title>FreeIPA, Apple OD, Gosa2, Novell eDirectory, FDS</title>
	<author>Anonymous</author>
	<datestamp>1244109060000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>I am with this task as well.</p><p>Since we need to support Kerberos, I had some difficulties to install OpenLDAP and manage the Kerberos and integrate with Samba and AFP.</p><p>Our servers are 80\% Linux and 20\% Windows,.<br>Our clients are 90\% Mac, 9\% Windows and 1\% Linuxes</p><p>I have messing with the follwoing solutions without much sucesse. They are all good, but they are NOT READY yet. Maybe Novell eDirectory, but I think it is too big and kind of expensive.</p><p>I really don't like Microsoft, so we are avoiding AD and avoiding supporting M$ with our money.</p><p>So, we tried:</p><p>- Fedora Directory Server<br>- OpenLDAP + Kerberos  (doesn't have a good admin interface)<br>- Gosa<br>- FreeIPA</p><p>But, we will keep investigating.</p><p>for now, our BEST OPTION and the easiest is:</p><p>Apple OD (Open Directory).<br>It integrate very well with Windows, Apple, Linux and has Kerberois and a great Admin UI</p><p>Ou ONLY problem with Apple is that we can't VMWare... so, that's the only issue for us!!!</p><p>In about 6 months we will try again the followings:</p><p>- FreeIPA<br>- Gosa2<br>- Fedora Directory Server</p></htmltext>
<tokenext>I am with this task as well.Since we need to support Kerberos , I had some difficulties to install OpenLDAP and manage the Kerberos and integrate with Samba and AFP.Our servers are 80 \ % Linux and 20 \ % Windows,.Our clients are 90 \ % Mac , 9 \ % Windows and 1 \ % LinuxesI have messing with the follwoing solutions without much sucesse .
They are all good , but they are NOT READY yet .
Maybe Novell eDirectory , but I think it is too big and kind of expensive.I really do n't like Microsoft , so we are avoiding AD and avoiding supporting M $ with our money.So , we tried : - Fedora Directory Server- OpenLDAP + Kerberos ( does n't have a good admin interface ) - Gosa- FreeIPABut , we will keep investigating.for now , our BEST OPTION and the easiest is : Apple OD ( Open Directory ) .It integrate very well with Windows , Apple , Linux and has Kerberois and a great Admin UIOu ONLY problem with Apple is that we ca n't VMWare... so , that 's the only issue for us ! !
! In about 6 months we will try again the followings : - FreeIPA- Gosa2- Fedora Directory Server</tokentext>
<sentencetext>I am with this task as well.Since we need to support Kerberos, I had some difficulties to install OpenLDAP and manage the Kerberos and integrate with Samba and AFP.Our servers are 80\% Linux and 20\% Windows,.Our clients are 90\% Mac, 9\% Windows and 1\% LinuxesI have messing with the follwoing solutions without much sucesse.
They are all good, but they are NOT READY yet.
Maybe Novell eDirectory, but I think it is too big and kind of expensive.I really don't like Microsoft, so we are avoiding AD and avoiding supporting M$ with our money.So, we tried:- Fedora Directory Server- OpenLDAP + Kerberos  (doesn't have a good admin interface)- Gosa- FreeIPABut, we will keep investigating.for now, our BEST OPTION and the easiest is:Apple OD (Open Directory).It integrate very well with Windows, Apple, Linux and has Kerberois and a great Admin UIOu ONLY problem with Apple is that we can't VMWare... so, that's the only issue for us!!
!In about 6 months we will try again the followings:- FreeIPA- Gosa2- Fedora Directory Server</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28217905</id>
	<title>Re:Easy</title>
	<author>Antique Geekmeister</author>
	<datestamp>1244130780000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext>I know quie a lot about LDAP, Kerberos, DNS, DHCP, and database back ends. I find Active Directory's pitfalls to be quite painful. (Its refusal to assign a hostname for broadcast or netmask addresses is just plain stupid.) And as you say, custom applications are difficult. (Try deploying djbdns for mail filtering of the dnsbl blacklist with Active Directory in place. Oh, dear, that was painful!!)

But \_everyone has clients that will work with it\_, And if you need a bit of your own services, such as a local DNS zone or a better secured and scriptable DHCP setup, that can be deployed alongside itl. The big problem is whether you can actually secure it in a corporate environment: the fear of installing security patches, and unwillingness to deploy them in proper failover configuraiton or with the ability to test new setups, has made them a single point of failure in many environments. So deploy them cautiouslyl</htmltext>
<tokenext>I know quie a lot about LDAP , Kerberos , DNS , DHCP , and database back ends .
I find Active Directory 's pitfalls to be quite painful .
( Its refusal to assign a hostname for broadcast or netmask addresses is just plain stupid .
) And as you say , custom applications are difficult .
( Try deploying djbdns for mail filtering of the dnsbl blacklist with Active Directory in place .
Oh , dear , that was painful ! !
) But \ _everyone has clients that will work with it \ _ , And if you need a bit of your own services , such as a local DNS zone or a better secured and scriptable DHCP setup , that can be deployed alongside itl .
The big problem is whether you can actually secure it in a corporate environment : the fear of installing security patches , and unwillingness to deploy them in proper failover configuraiton or with the ability to test new setups , has made them a single point of failure in many environments .
So deploy them cautiouslyl</tokentext>
<sentencetext>I know quie a lot about LDAP, Kerberos, DNS, DHCP, and database back ends.
I find Active Directory's pitfalls to be quite painful.
(Its refusal to assign a hostname for broadcast or netmask addresses is just plain stupid.
) And as you say, custom applications are difficult.
(Try deploying djbdns for mail filtering of the dnsbl blacklist with Active Directory in place.
Oh, dear, that was painful!!
)

But \_everyone has clients that will work with it\_, And if you need a bit of your own services, such as a local DNS zone or a better secured and scriptable DHCP setup, that can be deployed alongside itl.
The big problem is whether you can actually secure it in a corporate environment: the fear of installing security patches, and unwillingness to deploy them in proper failover configuraiton or with the ability to test new setups, has made them a single point of failure in many environments.
So deploy them cautiouslyl</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214343</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28222423</id>
	<title>Re:My choices</title>
	<author>luguvalium2</author>
	<datestamp>1244216820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>FYI: Centos Directory Server was recently released</p><p><a href="http://lists.centos.org/pipermail/centos-announce/2009-May/015943.html" title="centos.org" rel="nofollow">http://lists.centos.org/pipermail/centos-announce/2009-May/015943.html</a> [centos.org]</p><p><a href="http://wiki.centos.org/HowTos/DirectoryServerSetup" title="centos.org" rel="nofollow">http://wiki.centos.org/HowTos/DirectoryServerSetup</a> [centos.org]</p></htmltext>
<tokenext>FYI : Centos Directory Server was recently releasedhttp : //lists.centos.org/pipermail/centos-announce/2009-May/015943.html [ centos.org ] http : //wiki.centos.org/HowTos/DirectoryServerSetup [ centos.org ]</tokentext>
<sentencetext>FYI: Centos Directory Server was recently releasedhttp://lists.centos.org/pipermail/centos-announce/2009-May/015943.html [centos.org]http://wiki.centos.org/HowTos/DirectoryServerSetup [centos.org]</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213913</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28217065</id>
	<title>Here's what I'm trying at home this summer</title>
	<author>adriccom</author>
	<datestamp>1244121960000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Hi,

<p>I have felt your pain. I just got my used copy of <a href="http://www.amazon.com/gp/product/3540366334?ie=UTF8&amp;tag=adrnet-20&amp;linkCode=as2&amp;camp=1789&amp;creative=390957&amp;creativeASIN=3540366334" title="amazon.com" rel="nofollow">Distributed Services with OpenAFS: for Enterprise and Education</a> [amazon.com] and it looks pretty awesome so far.</p><p>It's a textbook of explanations wrapped around a whole bunch of script(1) captures of them setting up ntp,dns,k5,ldap,openafs,samba, etc on Debian with Windows, Mac, Ubuntu clients. You can find the table of contents and an excerpt at the book's site:
<a href="http://www.springer.com/computer/programming/book/978-3-540-36633-1" title="springer.com" rel="nofollow">http://www.springer.com/computer/programming/book/978-3-540-36633-1</a> [springer.com] </p><p>hth and Good Luck!</p><p>adric</p></htmltext>
<tokenext>Hi , I have felt your pain .
I just got my used copy of Distributed Services with OpenAFS : for Enterprise and Education [ amazon.com ] and it looks pretty awesome so far.It 's a textbook of explanations wrapped around a whole bunch of script ( 1 ) captures of them setting up ntp,dns,k5,ldap,openafs,samba , etc on Debian with Windows , Mac , Ubuntu clients .
You can find the table of contents and an excerpt at the book 's site : http : //www.springer.com/computer/programming/book/978-3-540-36633-1 [ springer.com ] hth and Good Luck ! adric</tokentext>
<sentencetext>Hi,

I have felt your pain.
I just got my used copy of Distributed Services with OpenAFS: for Enterprise and Education [amazon.com] and it looks pretty awesome so far.It's a textbook of explanations wrapped around a whole bunch of script(1) captures of them setting up ntp,dns,k5,ldap,openafs,samba, etc on Debian with Windows, Mac, Ubuntu clients.
You can find the table of contents and an excerpt at the book's site:
http://www.springer.com/computer/programming/book/978-3-540-36633-1 [springer.com] hth and Good Luck!adric</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214249</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28228161</id>
	<title>Re:AD</title>
	<author>Rysc</author>
	<datestamp>1244200320000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>You have got to be kidding.</p><p>AD is best only if you mean it's easy for a monkey to do the initial setup. If you want robustness, scalability and maintainability you will find nearly everything else is better.</p></htmltext>
<tokenext>You have got to be kidding.AD is best only if you mean it 's easy for a monkey to do the initial setup .
If you want robustness , scalability and maintainability you will find nearly everything else is better .</tokentext>
<sentencetext>You have got to be kidding.AD is best only if you mean it's easy for a monkey to do the initial setup.
If you want robustness, scalability and maintainability you will find nearly everything else is better.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214011</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28217171</id>
	<title>MDS - Mandriva Directory Server</title>
	<author>Player Parker</author>
	<datestamp>1244122800000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext>I find myself in the same situation and am considering either MDS or FDS, which is now 389 Directory Server btw, to address this need.

My goal is to stay away from Microsoft's AD primarily because my boss looks for $100 solutions for $10 (or less).

I won't banter on here about the merits of what MDS will and will not do, but I will say it's a very good package, well documented and certainly worth consideration.

I setup a VMware server which I'd be happy to ZIP up and post on our company's sftp site for you to download and check out if you so wish.

Look me up and I'll hook you up, no worries...</htmltext>
<tokenext>I find myself in the same situation and am considering either MDS or FDS , which is now 389 Directory Server btw , to address this need .
My goal is to stay away from Microsoft 's AD primarily because my boss looks for $ 100 solutions for $ 10 ( or less ) .
I wo n't banter on here about the merits of what MDS will and will not do , but I will say it 's a very good package , well documented and certainly worth consideration .
I setup a VMware server which I 'd be happy to ZIP up and post on our company 's sftp site for you to download and check out if you so wish .
Look me up and I 'll hook you up , no worries.. .</tokentext>
<sentencetext>I find myself in the same situation and am considering either MDS or FDS, which is now 389 Directory Server btw, to address this need.
My goal is to stay away from Microsoft's AD primarily because my boss looks for $100 solutions for $10 (or less).
I won't banter on here about the merits of what MDS will and will not do, but I will say it's a very good package, well documented and certainly worth consideration.
I setup a VMware server which I'd be happy to ZIP up and post on our company's sftp site for you to download and check out if you so wish.
Look me up and I'll hook you up, no worries...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28217423</id>
	<title>Re:My choices</title>
	<author>JSG</author>
	<datestamp>1244124900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>&gt;&gt;4.) Novell eDirectory (personally my least favorite)</p><p>Why?  Have you actually used it.  How does it compare to your other options?</p></htmltext>
<tokenext>&gt; &gt; 4 .
) Novell eDirectory ( personally my least favorite ) Why ?
Have you actually used it .
How does it compare to your other options ?</tokentext>
<sentencetext>&gt;&gt;4.
) Novell eDirectory (personally my least favorite)Why?
Have you actually used it.
How does it compare to your other options?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213913</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213777</id>
	<title>Stick with OpenLDAP ...</title>
	<author>Anonymous</author>
	<datestamp>1244147520000</datestamp>
	<modclass>None</modclass>
	<modscore>-1</modscore>
	<htmltext><p>I have designed and implemented the infrastructure for multiple startup environments over the past 10 years and while the trend seems to be to use Active Directory, my last two startups were made vastly easier by not using AD.  LDAP provides you with a great deal more control over the schema and capabilities needed for open source systems like Linux login, Wiki and other web based application login.  Openldap also gives you a great many ways of easily managing users via a multitude of applications whether host based or web based.  Most importantly, it will save you a LOT of money in the end and provide for far greater flexibility, availability and uptime.  And making LDAP a domain controller for your windows hosts is easily accomplished by using Samba integration.  Trust me, go LDAP<nobr> <wbr></nobr>...</p></htmltext>
<tokenext>I have designed and implemented the infrastructure for multiple startup environments over the past 10 years and while the trend seems to be to use Active Directory , my last two startups were made vastly easier by not using AD .
LDAP provides you with a great deal more control over the schema and capabilities needed for open source systems like Linux login , Wiki and other web based application login .
Openldap also gives you a great many ways of easily managing users via a multitude of applications whether host based or web based .
Most importantly , it will save you a LOT of money in the end and provide for far greater flexibility , availability and uptime .
And making LDAP a domain controller for your windows hosts is easily accomplished by using Samba integration .
Trust me , go LDAP .. .</tokentext>
<sentencetext>I have designed and implemented the infrastructure for multiple startup environments over the past 10 years and while the trend seems to be to use Active Directory, my last two startups were made vastly easier by not using AD.
LDAP provides you with a great deal more control over the schema and capabilities needed for open source systems like Linux login, Wiki and other web based application login.
Openldap also gives you a great many ways of easily managing users via a multitude of applications whether host based or web based.
Most importantly, it will save you a LOT of money in the end and provide for far greater flexibility, availability and uptime.
And making LDAP a domain controller for your windows hosts is easily accomplished by using Samba integration.
Trust me, go LDAP ...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28216247</id>
	<title>Nah!</title>
	<author>alexborges</author>
	<datestamp>1244116680000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>" it seems like it may be easiest to just use Active Directory for everything. Are there any pitfalls with this approach? "</p><p>No no no.</p><p>Go do samba+ldap and THEN you have BOTH windows and a linux directory. You might hear something about "group policies" and other crap, thats treated in-depth in the samba howto: you CAN deploy policies with a smb pdc to winxp-2k boxes without too much problem (youll need a cheap version of win2k and ads with minal cals to get the admin gui for that, but in no way should you pay CALs for your linux boxes: that is plain stupid).</p></htmltext>
<tokenext>" it seems like it may be easiest to just use Active Directory for everything .
Are there any pitfalls with this approach ?
" No no no.Go do samba + ldap and THEN you have BOTH windows and a linux directory .
You might hear something about " group policies " and other crap , thats treated in-depth in the samba howto : you CAN deploy policies with a smb pdc to winxp-2k boxes without too much problem ( youll need a cheap version of win2k and ads with minal cals to get the admin gui for that , but in no way should you pay CALs for your linux boxes : that is plain stupid ) .</tokentext>
<sentencetext>" it seems like it may be easiest to just use Active Directory for everything.
Are there any pitfalls with this approach?
"No no no.Go do samba+ldap and THEN you have BOTH windows and a linux directory.
You might hear something about "group policies" and other crap, thats treated in-depth in the samba howto: you CAN deploy policies with a smb pdc to winxp-2k boxes without too much problem (youll need a cheap version of win2k and ads with minal cals to get the admin gui for that, but in no way should you pay CALs for your linux boxes: that is plain stupid).</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28219171</id>
	<title>Re:Novell.......no seriously</title>
	<author>Techman83</author>
	<datestamp>1244232000000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Yeah we administer AD using IDM. Everything gets done in eDir, which is much faster and less frustrating, then it flows onto AD automatically.</htmltext>
<tokenext>Yeah we administer AD using IDM .
Everything gets done in eDir , which is much faster and less frustrating , then it flows onto AD automatically .</tokentext>
<sentencetext>Yeah we administer AD using IDM.
Everything gets done in eDir, which is much faster and less frustrating, then it flows onto AD automatically.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213799</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28215915</id>
	<title>Re:Just go with AD</title>
	<author>anom</author>
	<datestamp>1244114820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>What linux distro do you use?</p><p>Try Likewise Open.  I know it works for more, but for ubuntu, it's this easy:  <a href="https://help.ubuntu.com/8.04/serverguide/C/likewise-open.html" title="ubuntu.com" rel="nofollow">https://help.ubuntu.com/8.04/serverguide/C/likewise-open.html</a> [ubuntu.com]</p><p>It's seriously 2 commands to join it to a windows domain.</p></htmltext>
<tokenext>What linux distro do you use ? Try Likewise Open .
I know it works for more , but for ubuntu , it 's this easy : https : //help.ubuntu.com/8.04/serverguide/C/likewise-open.html [ ubuntu.com ] It 's seriously 2 commands to join it to a windows domain .</tokentext>
<sentencetext>What linux distro do you use?Try Likewise Open.
I know it works for more, but for ubuntu, it's this easy:  https://help.ubuntu.com/8.04/serverguide/C/likewise-open.html [ubuntu.com]It's seriously 2 commands to join it to a windows domain.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214249</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213753</id>
	<title>shot in the dark</title>
	<author>Anonymous</author>
	<datestamp>1244147400000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>i took a class once where we used LDAP (Lightweight Directory Access Protocol) and then used Ubuntu and VMware to setup multiple Ubuntu/Win2k/WinServer2k3 all with roaming profiles and active directories.</p><p>it worked great and was a really fun class also.</p></htmltext>
<tokenext>i took a class once where we used LDAP ( Lightweight Directory Access Protocol ) and then used Ubuntu and VMware to setup multiple Ubuntu/Win2k/WinServer2k3 all with roaming profiles and active directories.it worked great and was a really fun class also .</tokentext>
<sentencetext>i took a class once where we used LDAP (Lightweight Directory Access Protocol) and then used Ubuntu and VMware to setup multiple Ubuntu/Win2k/WinServer2k3 all with roaming profiles and active directories.it worked great and was a really fun class also.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28215047</id>
	<title>If you want to use kerberos...</title>
	<author>profplump</author>
	<datestamp>1244110440000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>If you want to use kerberos you'll need to avoid Active Directory -- it does not play well with others. AD is a decent directory server, but the "kerberos" implementation muxes authorization and authentication and will not work with external kerberos servers at all.</p><p>On the other hand, AD does play very well with Windows desktops -- it is the only way to use certain administrative functions in Windows -- and is perfectly suitable for password-based authentication against the directory sever from any platform. So if you don't need kerberos AD is probably fine, though I'm not sure it's any better than RHDS or eDirectory or the like if all you're doing is centralized, password-based authentication.</p></htmltext>
<tokenext>If you want to use kerberos you 'll need to avoid Active Directory -- it does not play well with others .
AD is a decent directory server , but the " kerberos " implementation muxes authorization and authentication and will not work with external kerberos servers at all.On the other hand , AD does play very well with Windows desktops -- it is the only way to use certain administrative functions in Windows -- and is perfectly suitable for password-based authentication against the directory sever from any platform .
So if you do n't need kerberos AD is probably fine , though I 'm not sure it 's any better than RHDS or eDirectory or the like if all you 're doing is centralized , password-based authentication .</tokentext>
<sentencetext>If you want to use kerberos you'll need to avoid Active Directory -- it does not play well with others.
AD is a decent directory server, but the "kerberos" implementation muxes authorization and authentication and will not work with external kerberos servers at all.On the other hand, AD does play very well with Windows desktops -- it is the only way to use certain administrative functions in Windows -- and is perfectly suitable for password-based authentication against the directory sever from any platform.
So if you don't need kerberos AD is probably fine, though I'm not sure it's any better than RHDS or eDirectory or the like if all you're doing is centralized, password-based authentication.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28217445</id>
	<title>Re:My choices</title>
	<author>JSG</author>
	<datestamp>1244125200000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>eDirectory AKA NDS was based on X400 as I recall.  I remember using it in 1993, before Netscape was formed - "Netscape stock traded between 1995 and 2003" - Wikipedia</p></htmltext>
<tokenext>eDirectory AKA NDS was based on X400 as I recall .
I remember using it in 1993 , before Netscape was formed - " Netscape stock traded between 1995 and 2003 " - Wikipedia</tokentext>
<sentencetext>eDirectory AKA NDS was based on X400 as I recall.
I remember using it in 1993, before Netscape was formed - "Netscape stock traded between 1995 and 2003" - Wikipedia</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214335</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213867</id>
	<title>Some tools aren't up to the challenge....</title>
	<author>SomeoneGotMyNick</author>
	<datestamp>1244147820000</datestamp>
	<modclass>None</modclass>
	<modscore>-1</modscore>
	<htmltext><p>Gee, I hope they don't try and implement any kind of directory service implementation from <a href="http://scratch.mit.edu/" title="mit.edu" rel="nofollow">Scratch</a> [mit.edu]</p></htmltext>
<tokenext>Gee , I hope they do n't try and implement any kind of directory service implementation from Scratch [ mit.edu ]</tokentext>
<sentencetext>Gee, I hope they don't try and implement any kind of directory service implementation from Scratch [mit.edu]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28219007</id>
	<title>Who came up with the Cerebrum logo?</title>
	<author>joib</author>
	<datestamp>1244143020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Looks like these vagina pictures you find in the  gents rooms worldwide.</p><p>Yes, I realize it's supposed to be a brain, but just saying, just saying..</p></htmltext>
<tokenext>Looks like these vagina pictures you find in the gents rooms worldwide.Yes , I realize it 's supposed to be a brain , but just saying , just saying. .</tokentext>
<sentencetext>Looks like these vagina pictures you find in the  gents rooms worldwide.Yes, I realize it's supposed to be a brain, but just saying, just saying..</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214365</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28217095</id>
	<title>Re:Easy</title>
	<author>Blakey Rat</author>
	<datestamp>1244122200000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><i>You're not a developer, are you? Whether or not AD is a dream to work with depends heavily on what your job description is. If you are simply an administrator plugging random Windows or even Linux and *nix boxes into AD you might find it comparatively easy. If on the other hand you expect to have to develop custom applications of your own on non-Microsoft platforms that authenticate against AD or convert existing ones to use AD then it can be a painful experience to use AD. It's not an unsolvable problem mind you, just a really annoying one.</i></p><p>Unless you're a Windows developer, in which case you can just drag&amp;drop the<nobr> <wbr></nobr>.net sign-on control into your project and you're done in 5 seconds.</p></htmltext>
<tokenext>You 're not a developer , are you ?
Whether or not AD is a dream to work with depends heavily on what your job description is .
If you are simply an administrator plugging random Windows or even Linux and * nix boxes into AD you might find it comparatively easy .
If on the other hand you expect to have to develop custom applications of your own on non-Microsoft platforms that authenticate against AD or convert existing ones to use AD then it can be a painful experience to use AD .
It 's not an unsolvable problem mind you , just a really annoying one.Unless you 're a Windows developer , in which case you can just drag&amp;drop the .net sign-on control into your project and you 're done in 5 seconds .</tokentext>
<sentencetext>You're not a developer, are you?
Whether or not AD is a dream to work with depends heavily on what your job description is.
If you are simply an administrator plugging random Windows or even Linux and *nix boxes into AD you might find it comparatively easy.
If on the other hand you expect to have to develop custom applications of your own on non-Microsoft platforms that authenticate against AD or convert existing ones to use AD then it can be a painful experience to use AD.
It's not an unsolvable problem mind you, just a really annoying one.Unless you're a Windows developer, in which case you can just drag&amp;drop the .net sign-on control into your project and you're done in 5 seconds.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214343</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28219273</id>
	<title>Re:My choices</title>
	<author>kylegordon</author>
	<datestamp>1244233380000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>SunDS, FDS and Novell eDirectory are all based on Netscapes DS</p></div><p>Timeline issues notwithstanding, I think you're confusing Novell Directory Services and Netscape Directory Services. The former came before the latter, although they both have the same acronym.</p></div>
	</htmltext>
<tokenext>SunDS , FDS and Novell eDirectory are all based on Netscapes DSTimeline issues notwithstanding , I think you 're confusing Novell Directory Services and Netscape Directory Services .
The former came before the latter , although they both have the same acronym .</tokentext>
<sentencetext>SunDS, FDS and Novell eDirectory are all based on Netscapes DSTimeline issues notwithstanding, I think you're confusing Novell Directory Services and Netscape Directory Services.
The former came before the latter, although they both have the same acronym.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214335</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214935</id>
	<title>Re:Stick with OpenLDAP ...</title>
	<author>Anonymous</author>
	<datestamp>1244109780000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>First off, AD does provide LDAP services, it is Active<strong>DIRECTORY</strong> after all.</p><p>Second, every OSS app out there pretty much lets you modify the schema it expects from the server, meaning making it talk to an ActiveDirectory server is just a matter of properly setting up the schema.   Hell most apps now days already have an example config for talking to a stock ActiveDirectory, but you're better off with AD + Services for Unix so you get AD and Unix UID/GID administration in one pretty point and clicky interface.</p><p>Other than having a more flexible schema, since it doesn't assume you need to talk to windows, its inferior to AD in just about every other way, excluding price, where of course it beats the shit out of AD<nobr> <wbr></nobr>:)</p><p>If your last two startups were made easier by not using AD, you have incompetent admins who don't actually understand ldap or kerberos.</p><p>With openldap you get a directory, which CAN be used to authenticate, but thats not what you should be doing.  Kerberos is accepted everywhere as the best authentication system to use in an organization, hands down, Unix OR windows.  With AD you get both.  Which means instead of using your crappy 'bind to auth' or 'bind as someone then query to auth' and 'hopefully we remembered to use SSL everywhere that needs auth', with AD you get LDAP + kerberos for auth, best of both worlds.</p><p>AD allows you to manage users with those same applications, host or web based as it support LDAP perfectly so OpenLDAP doesn't have anything on it there.</p><p>Fourth, you can just make samba join your activedirectory server instead of making it pretend to be one and dealing with all the quirks that goes with that if you have anything beyond the most simple of setups.</p><p>Want samba to join ads?   Install samba 3 or newer, install a time sync utility if you don't already have one, type:</p><p>net ads join</p><p>Follow prompts, done.</p><p>Go the next step and tell samba to generate a keytab for kerberos for you and be happy as now you can start using kerberos for other services rather a cobbled together bunch of hacks to bindauth or queryauth off the ldap server.</p><p>Me thinks you don't really have any actual experience with or an idea what AD is.  AD is NOT  NTDOMAINS, even though an AD server is capable of providing backwards compatibility, it is not required and if you're using not using anything older than XP and unix machines it should be turned off.</p><p>OpenLDAP is only a partial replacement for ActiveDirectory, and really is the WRONG way to do authentication.  MS didn't invent kerberos, but switching to it was one of those 'Okay, you win, we're on the bandwagon with your protocols' moments that you should actually thank them for and look into.  Stop hating and educate yourself.</p><p>What OpenLDAP wins at, hands down, is of course, cost.  But its really silly to say that its more flexible or more reliable (which, btw availability and uptime mean the same thing here).</p><p>Do you want to use a bunch of hacks to make your windows machines authenticate, or would you rather use a system that supports everyone natively and completely, Windows AND Unix (including OSX)?  Personally I went with AD so I can just do everything natively, with Services for UNIX the thing will even function as a NIS (maybe NIS+, I don't use that part) server if you've got old boxes that you need to pull into the group.</p></htmltext>
<tokenext>First off , AD does provide LDAP services , it is ActiveDIRECTORY after all.Second , every OSS app out there pretty much lets you modify the schema it expects from the server , meaning making it talk to an ActiveDirectory server is just a matter of properly setting up the schema .
Hell most apps now days already have an example config for talking to a stock ActiveDirectory , but you 're better off with AD + Services for Unix so you get AD and Unix UID/GID administration in one pretty point and clicky interface.Other than having a more flexible schema , since it does n't assume you need to talk to windows , its inferior to AD in just about every other way , excluding price , where of course it beats the shit out of AD : ) If your last two startups were made easier by not using AD , you have incompetent admins who do n't actually understand ldap or kerberos.With openldap you get a directory , which CAN be used to authenticate , but thats not what you should be doing .
Kerberos is accepted everywhere as the best authentication system to use in an organization , hands down , Unix OR windows .
With AD you get both .
Which means instead of using your crappy 'bind to auth ' or 'bind as someone then query to auth ' and 'hopefully we remembered to use SSL everywhere that needs auth ' , with AD you get LDAP + kerberos for auth , best of both worlds.AD allows you to manage users with those same applications , host or web based as it support LDAP perfectly so OpenLDAP does n't have anything on it there.Fourth , you can just make samba join your activedirectory server instead of making it pretend to be one and dealing with all the quirks that goes with that if you have anything beyond the most simple of setups.Want samba to join ads ?
Install samba 3 or newer , install a time sync utility if you do n't already have one , type : net ads joinFollow prompts , done.Go the next step and tell samba to generate a keytab for kerberos for you and be happy as now you can start using kerberos for other services rather a cobbled together bunch of hacks to bindauth or queryauth off the ldap server.Me thinks you do n't really have any actual experience with or an idea what AD is .
AD is NOT NTDOMAINS , even though an AD server is capable of providing backwards compatibility , it is not required and if you 're using not using anything older than XP and unix machines it should be turned off.OpenLDAP is only a partial replacement for ActiveDirectory , and really is the WRONG way to do authentication .
MS did n't invent kerberos , but switching to it was one of those 'Okay , you win , we 're on the bandwagon with your protocols ' moments that you should actually thank them for and look into .
Stop hating and educate yourself.What OpenLDAP wins at , hands down , is of course , cost .
But its really silly to say that its more flexible or more reliable ( which , btw availability and uptime mean the same thing here ) .Do you want to use a bunch of hacks to make your windows machines authenticate , or would you rather use a system that supports everyone natively and completely , Windows AND Unix ( including OSX ) ?
Personally I went with AD so I can just do everything natively , with Services for UNIX the thing will even function as a NIS ( maybe NIS + , I do n't use that part ) server if you 've got old boxes that you need to pull into the group .</tokentext>
<sentencetext>First off, AD does provide LDAP services, it is ActiveDIRECTORY after all.Second, every OSS app out there pretty much lets you modify the schema it expects from the server, meaning making it talk to an ActiveDirectory server is just a matter of properly setting up the schema.
Hell most apps now days already have an example config for talking to a stock ActiveDirectory, but you're better off with AD + Services for Unix so you get AD and Unix UID/GID administration in one pretty point and clicky interface.Other than having a more flexible schema, since it doesn't assume you need to talk to windows, its inferior to AD in just about every other way, excluding price, where of course it beats the shit out of AD :)If your last two startups were made easier by not using AD, you have incompetent admins who don't actually understand ldap or kerberos.With openldap you get a directory, which CAN be used to authenticate, but thats not what you should be doing.
Kerberos is accepted everywhere as the best authentication system to use in an organization, hands down, Unix OR windows.
With AD you get both.
Which means instead of using your crappy 'bind to auth' or 'bind as someone then query to auth' and 'hopefully we remembered to use SSL everywhere that needs auth', with AD you get LDAP + kerberos for auth, best of both worlds.AD allows you to manage users with those same applications, host or web based as it support LDAP perfectly so OpenLDAP doesn't have anything on it there.Fourth, you can just make samba join your activedirectory server instead of making it pretend to be one and dealing with all the quirks that goes with that if you have anything beyond the most simple of setups.Want samba to join ads?
Install samba 3 or newer, install a time sync utility if you don't already have one, type:net ads joinFollow prompts, done.Go the next step and tell samba to generate a keytab for kerberos for you and be happy as now you can start using kerberos for other services rather a cobbled together bunch of hacks to bindauth or queryauth off the ldap server.Me thinks you don't really have any actual experience with or an idea what AD is.
AD is NOT  NTDOMAINS, even though an AD server is capable of providing backwards compatibility, it is not required and if you're using not using anything older than XP and unix machines it should be turned off.OpenLDAP is only a partial replacement for ActiveDirectory, and really is the WRONG way to do authentication.
MS didn't invent kerberos, but switching to it was one of those 'Okay, you win, we're on the bandwagon with your protocols' moments that you should actually thank them for and look into.
Stop hating and educate yourself.What OpenLDAP wins at, hands down, is of course, cost.
But its really silly to say that its more flexible or more reliable (which, btw availability and uptime mean the same thing here).Do you want to use a bunch of hacks to make your windows machines authenticate, or would you rather use a system that supports everyone natively and completely, Windows AND Unix (including OSX)?
Personally I went with AD so I can just do everything natively, with Services for UNIX the thing will even function as a NIS (maybe NIS+, I don't use that part) server if you've got old boxes that you need to pull into the group.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213777</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28220275</id>
	<title>Identity Management</title>
	<author>Anonymous</author>
	<datestamp>1244204100000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>What you have here is a chance to implement a proper Identity management system.</p><p>The effort you intend to invest is comparable to that required to implement a system such as IBM's Tivoli Identity Manager. This will give you a central point of administration like a directory service, but also allow you to cleanup, manage your user ids, implement role base access, use workflow to perform Business need reviews, employment verification and that's just for starters.</p></htmltext>
<tokenext>What you have here is a chance to implement a proper Identity management system.The effort you intend to invest is comparable to that required to implement a system such as IBM 's Tivoli Identity Manager .
This will give you a central point of administration like a directory service , but also allow you to cleanup , manage your user ids , implement role base access , use workflow to perform Business need reviews , employment verification and that 's just for starters .</tokentext>
<sentencetext>What you have here is a chance to implement a proper Identity management system.The effort you intend to invest is comparable to that required to implement a system such as IBM's Tivoli Identity Manager.
This will give you a central point of administration like a directory service, but also allow you to cleanup, manage your user ids, implement role base access, use workflow to perform Business need reviews, employment verification and that's just for starters.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213723</id>
	<title>Easy</title>
	<author>ChadAmberg</author>
	<datestamp>1244147340000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>Use AD.<br>Even though folks will fuss and whine about AD being not pure LDAP, for all intents and purposes it is, and we've got lots of Linux and other *nix boxes using it for authentication.  And remember, you can always extend AD for your custom applications easy enough.  It's simple enough that MCSEs can run it.</p></htmltext>
<tokenext>Use AD.Even though folks will fuss and whine about AD being not pure LDAP , for all intents and purposes it is , and we 've got lots of Linux and other * nix boxes using it for authentication .
And remember , you can always extend AD for your custom applications easy enough .
It 's simple enough that MCSEs can run it .</tokentext>
<sentencetext>Use AD.Even though folks will fuss and whine about AD being not pure LDAP, for all intents and purposes it is, and we've got lots of Linux and other *nix boxes using it for authentication.
And remember, you can always extend AD for your custom applications easy enough.
It's simple enough that MCSEs can run it.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213733</id>
	<title>David Carradine Has Died, He Was Delicious</title>
	<author>Anonymous</author>
	<datestamp>1244147340000</datestamp>
	<modclass>Offtopic</modclass>
	<modscore>-1</modscore>
	<htmltext><p>Apparently Carradine was eaten by wolves on the Connecticut turn-pike. All reports say he was delicious. Words cannot describe how sad this is. Carradine's acting was not exactly top-notch...even for the hey-day of 60's Kung-fu pop culture. His colour (a colour option picked up from an earlier version) clashes with the grey of any other living actors; that can be changed though. The black side of his acting in Kill Bill (Vol. 1 &amp; 2) is overbearing and doesn't meld with his earlier works. His *cough* apparent suicide *cough* stands out like a sore thumb. I somehow feel like his death resembles the chrome looks like a webpage, rather than someone who won an award in 2005 for lifetime acting achievements and for browsing web pages. I cannot believe someone who created the Firefox icon could star in something so hideous and inappropriate, especially when David Carradine's marketshare is bad enough already. I could not bear to look at this all day, every day, it would drive me mad.</p><p>A suicidal has-been Kung-fu actor should be transparent, a thin veneer between me and the web page. Not a clown honking his horn in my face. I went into preferences and changed to the Mac "native" theme and no particular colour, mildly improved, but still the black is overpowering, the new-tab button is the wrong colour, and the side pane has a tinge of blue that doesnt work well with the OS X grey. The tab touching the title bar also just looks poor and conflicting. This is the same bullshit I had to put up with when Dana Plato finally offed herself. It's goudy, non-native, clashes with the websites you view, and generally gets in the way, the toolkit underneath still rears it's ugly head in how the app works, and the general layout of the widgets. The dialogues throughout the app crap all over the spacing guides in the HIG. Every inch of this app is annoying and grates on me. I'm not an interface elitist or an apple fanboy, but I can't use software that gets on my nerves and Opera and Vista occupy the top two slots for that. The browser is eclectic, with too many preferences, too complicated preferences, too many customisation options. Features not everybody needs, or wants.</p></htmltext>
<tokenext>Apparently Carradine was eaten by wolves on the Connecticut turn-pike .
All reports say he was delicious .
Words can not describe how sad this is .
Carradine 's acting was not exactly top-notch...even for the hey-day of 60 's Kung-fu pop culture .
His colour ( a colour option picked up from an earlier version ) clashes with the grey of any other living actors ; that can be changed though .
The black side of his acting in Kill Bill ( Vol .
1 &amp; 2 ) is overbearing and does n't meld with his earlier works .
His * cough * apparent suicide * cough * stands out like a sore thumb .
I somehow feel like his death resembles the chrome looks like a webpage , rather than someone who won an award in 2005 for lifetime acting achievements and for browsing web pages .
I can not believe someone who created the Firefox icon could star in something so hideous and inappropriate , especially when David Carradine 's marketshare is bad enough already .
I could not bear to look at this all day , every day , it would drive me mad.A suicidal has-been Kung-fu actor should be transparent , a thin veneer between me and the web page .
Not a clown honking his horn in my face .
I went into preferences and changed to the Mac " native " theme and no particular colour , mildly improved , but still the black is overpowering , the new-tab button is the wrong colour , and the side pane has a tinge of blue that doesnt work well with the OS X grey .
The tab touching the title bar also just looks poor and conflicting .
This is the same bullshit I had to put up with when Dana Plato finally offed herself .
It 's goudy , non-native , clashes with the websites you view , and generally gets in the way , the toolkit underneath still rears it 's ugly head in how the app works , and the general layout of the widgets .
The dialogues throughout the app crap all over the spacing guides in the HIG .
Every inch of this app is annoying and grates on me .
I 'm not an interface elitist or an apple fanboy , but I ca n't use software that gets on my nerves and Opera and Vista occupy the top two slots for that .
The browser is eclectic , with too many preferences , too complicated preferences , too many customisation options .
Features not everybody needs , or wants .</tokentext>
<sentencetext>Apparently Carradine was eaten by wolves on the Connecticut turn-pike.
All reports say he was delicious.
Words cannot describe how sad this is.
Carradine's acting was not exactly top-notch...even for the hey-day of 60's Kung-fu pop culture.
His colour (a colour option picked up from an earlier version) clashes with the grey of any other living actors; that can be changed though.
The black side of his acting in Kill Bill (Vol.
1 &amp; 2) is overbearing and doesn't meld with his earlier works.
His *cough* apparent suicide *cough* stands out like a sore thumb.
I somehow feel like his death resembles the chrome looks like a webpage, rather than someone who won an award in 2005 for lifetime acting achievements and for browsing web pages.
I cannot believe someone who created the Firefox icon could star in something so hideous and inappropriate, especially when David Carradine's marketshare is bad enough already.
I could not bear to look at this all day, every day, it would drive me mad.A suicidal has-been Kung-fu actor should be transparent, a thin veneer between me and the web page.
Not a clown honking his horn in my face.
I went into preferences and changed to the Mac "native" theme and no particular colour, mildly improved, but still the black is overpowering, the new-tab button is the wrong colour, and the side pane has a tinge of blue that doesnt work well with the OS X grey.
The tab touching the title bar also just looks poor and conflicting.
This is the same bullshit I had to put up with when Dana Plato finally offed herself.
It's goudy, non-native, clashes with the websites you view, and generally gets in the way, the toolkit underneath still rears it's ugly head in how the app works, and the general layout of the widgets.
The dialogues throughout the app crap all over the spacing guides in the HIG.
Every inch of this app is annoying and grates on me.
I'm not an interface elitist or an apple fanboy, but I can't use software that gets on my nerves and Opera and Vista occupy the top two slots for that.
The browser is eclectic, with too many preferences, too complicated preferences, too many customisation options.
Features not everybody needs, or wants.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28220891</id>
	<title>Openldap FTW</title>
	<author>NilsCant</author>
	<datestamp>1244209440000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Our company went for openldap because we weren't getting any money at the time.
Everything was running Debian on old workstations.

A few years later, we got money for hardware, and we've built around what we had and ended up with quite a cool setup. Pretty much all based on Debian stable and FOSS.

I haven't used AD before, so I can't say openldap will be better, however it pretty much does what we need it to.

We have e-mail routing based on ldap attributes with postfix, authentication and authorization for courier-imap and pop, apache http auth, intranet (drupal), bugzilla, Request Tracker, kbox, jabber...
Recently, we got some Cisco ASA's for vpn client usage, which can do authentication and authorization based on LDAP.

For the Windows machines, we've got a domain with samba 3 that uses openldap as backend. That works great. We just don't have group policy, which would be nice to have, but I've read here that it ought to work even with samba, so maybe we could look into that as well.
All of our ldap traffic is nicely secured with TLS and SSL, and the datase is replicated to a dozen LDAP slaves in all of our worldwide offices.
We also query the db for contact details from the mail client and our contact page on the intranet, as does our avaya phone system to find phone numbers and even some of the fax machines we've got.
(And address book/mobile phone sync)

We also don't have to worry about licensing, which is quite nice when you want to try something out with a testbed or want to do some redundancy.</htmltext>
<tokenext>Our company went for openldap because we were n't getting any money at the time .
Everything was running Debian on old workstations .
A few years later , we got money for hardware , and we 've built around what we had and ended up with quite a cool setup .
Pretty much all based on Debian stable and FOSS .
I have n't used AD before , so I ca n't say openldap will be better , however it pretty much does what we need it to .
We have e-mail routing based on ldap attributes with postfix , authentication and authorization for courier-imap and pop , apache http auth , intranet ( drupal ) , bugzilla , Request Tracker , kbox , jabber.. . Recently , we got some Cisco ASA 's for vpn client usage , which can do authentication and authorization based on LDAP .
For the Windows machines , we 've got a domain with samba 3 that uses openldap as backend .
That works great .
We just do n't have group policy , which would be nice to have , but I 've read here that it ought to work even with samba , so maybe we could look into that as well .
All of our ldap traffic is nicely secured with TLS and SSL , and the datase is replicated to a dozen LDAP slaves in all of our worldwide offices .
We also query the db for contact details from the mail client and our contact page on the intranet , as does our avaya phone system to find phone numbers and even some of the fax machines we 've got .
( And address book/mobile phone sync ) We also do n't have to worry about licensing , which is quite nice when you want to try something out with a testbed or want to do some redundancy .</tokentext>
<sentencetext>Our company went for openldap because we weren't getting any money at the time.
Everything was running Debian on old workstations.
A few years later, we got money for hardware, and we've built around what we had and ended up with quite a cool setup.
Pretty much all based on Debian stable and FOSS.
I haven't used AD before, so I can't say openldap will be better, however it pretty much does what we need it to.
We have e-mail routing based on ldap attributes with postfix, authentication and authorization for courier-imap and pop, apache http auth, intranet (drupal), bugzilla, Request Tracker, kbox, jabber...
Recently, we got some Cisco ASA's for vpn client usage, which can do authentication and authorization based on LDAP.
For the Windows machines, we've got a domain with samba 3 that uses openldap as backend.
That works great.
We just don't have group policy, which would be nice to have, but I've read here that it ought to work even with samba, so maybe we could look into that as well.
All of our ldap traffic is nicely secured with TLS and SSL, and the datase is replicated to a dozen LDAP slaves in all of our worldwide offices.
We also query the db for contact details from the mail client and our contact page on the intranet, as does our avaya phone system to find phone numbers and even some of the fax machines we've got.
(And address book/mobile phone sync)

We also don't have to worry about licensing, which is quite nice when you want to try something out with a testbed or want to do some redundancy.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28219263</id>
	<title>NDS</title>
	<author>neurosine</author>
	<datestamp>1244233320000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I'd take a look at Novell Directory Services. I think it's called eDirectory now. Although the company I work for has almost exclusively windows based environments, I'm not a fan of the Jet database engine or its derivitaves many of these services are based on. If Windows users and PC's are in the minority, NDS would probably be an ideal solution.</htmltext>
<tokenext>I 'd take a look at Novell Directory Services .
I think it 's called eDirectory now .
Although the company I work for has almost exclusively windows based environments , I 'm not a fan of the Jet database engine or its derivitaves many of these services are based on .
If Windows users and PC 's are in the minority , NDS would probably be an ideal solution .</tokentext>
<sentencetext>I'd take a look at Novell Directory Services.
I think it's called eDirectory now.
Although the company I work for has almost exclusively windows based environments, I'm not a fan of the Jet database engine or its derivitaves many of these services are based on.
If Windows users and PC's are in the minority, NDS would probably be an ideal solution.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28217341</id>
	<title>Re:Support</title>
	<author>Majestix</author>
	<datestamp>1244124120000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Find someone to come in and tell you,</p><p>"Ah, we can fix this.  We'll just replace it with an MS AD server.  Oh wait, you want to keep this?  Why ever for?"</p><p>Those are a dime a dozen.  Well ok, considerably more than a dime.  But they make themselves sound soooo wonderful...</p></htmltext>
<tokenext>Find someone to come in and tell you , " Ah , we can fix this .
We 'll just replace it with an MS AD server .
Oh wait , you want to keep this ?
Why ever for ?
" Those are a dime a dozen .
Well ok , considerably more than a dime .
But they make themselves sound soooo wonderful.. .</tokentext>
<sentencetext>Find someone to come in and tell you,"Ah, we can fix this.
We'll just replace it with an MS AD server.
Oh wait, you want to keep this?
Why ever for?
"Those are a dime a dozen.
Well ok, considerably more than a dime.
But they make themselves sound soooo wonderful...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214161</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28224905</id>
	<title>Re:Start with SQL</title>
	<author>Tmack</author>
	<datestamp>1244226120000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p><div class="quote"><p>Yes, SQL. If you keep your raw data in SQL, it is easy to export data to any format you might need now or in the future.</p></div><p>
slapcat &gt; myldaptree.ldiff</p><p>

Done. You now have an Ldiff file that can be re-imported directly, or parsed quite easily, not sure why Exporting seems difficult?</p><p><div class="quote"><p>LDAP gets you a long way, but you will sooner or later end up with several apps that don't support it. The result is horrible password sync hacks, multiple passwords per user, etc.</p></div><p>
gssapi/SASL, or if its a horribly broken ap that doesnt do that either, its trivial to write an authorize/authenticate plugin for it, just about everything supports LDAP though, or  "AD" which is usually LDAP with the MS schema in mind that can be bent to use a normal LDAP directory instead. Password sync (to get the broken NT4/LANMAN and KRB5 passwords) is as simple as compiling smbk5pwd (for openldap) and making sure the things allowed to change user passwords only use the passwd exop in LDAP, which pam and most other items that can allow that have an option for. Its not a hack, though you do end up with several different hashes of the same thing, as intended, but you can thank MS and MIT for using their own standard for hashing instead of plug-in cryptos, and pushing that for use in certain standards (WPA2 and Kerberos)<nobr> <wbr></nobr>.</p><p><div class="quote"><p>The idea is to put raw user info in SQL, including their clear-text password.</p> </div><p>
Um, no. All it takes is one rogue admin with the access to "Manage" that database, and suddenly they can pull the CEO's password without anyone noticing, or a misconfigured SQL server running a non-ssl connection leaking that plain-text across the wire. If you are properly implementing a two-factor system (rsa securid or some equiv) this isnt as big a deal, but still... no.</p><p><div class="quote"><p>Of course, lock down that SQL server like you've never locked down anything before! It should have a very limited interface for updating user data.</p> </div><p>You should do this with any machine regardless. Lock it down so only those that need it can get in, and they only have access to what needs to be worked on... standard policy</p><p><div class="quote"><p>Next, export user data to relevant external databases such as LDAP, NIS, SASL, that obscure sqlite app, Kerberos, DMZ services, etc, and you'll have much less pain keeping everything in sync.</p></div><p>Why? You end up with multiple copies of the same data spread across a multitude of disparate systems. OpenLDAP plugs directly into SASL, Kerberos, Samba, Securid, FreeRadius and many other systems that are NOT really directories and therefore should not have the data themselves. Instead they query LDAP for what they need, and LDAP is configured to let them read only what they need, securely (access to attrs=BLAH by ssf=128 dn.exact="cn=someapp,dc=example,dc=com" read). The ssl certs required are trivial to setup, just use CA.pl a few times, create a CA and a few test certs and you quickly get the hang of it. Setting up LDAPS is generally easier than trying to make sure all your SQL connections are secure as well (only start the ldaps service instead of ldap+ldaps, and use ssf=128 for all acls). With that in place, there is absolutely no risk of sending plain-text passwords in the clear over the wire, where your sql implementation seems ready and willing to do exactly that.</p><p>-T</p></div>
	</htmltext>
<tokenext>Yes , SQL .
If you keep your raw data in SQL , it is easy to export data to any format you might need now or in the future .
slapcat &gt; myldaptree.ldiff Done .
You now have an Ldiff file that can be re-imported directly , or parsed quite easily , not sure why Exporting seems difficult ? LDAP gets you a long way , but you will sooner or later end up with several apps that do n't support it .
The result is horrible password sync hacks , multiple passwords per user , etc .
gssapi/SASL , or if its a horribly broken ap that doesnt do that either , its trivial to write an authorize/authenticate plugin for it , just about everything supports LDAP though , or " AD " which is usually LDAP with the MS schema in mind that can be bent to use a normal LDAP directory instead .
Password sync ( to get the broken NT4/LANMAN and KRB5 passwords ) is as simple as compiling smbk5pwd ( for openldap ) and making sure the things allowed to change user passwords only use the passwd exop in LDAP , which pam and most other items that can allow that have an option for .
Its not a hack , though you do end up with several different hashes of the same thing , as intended , but you can thank MS and MIT for using their own standard for hashing instead of plug-in cryptos , and pushing that for use in certain standards ( WPA2 and Kerberos ) .The idea is to put raw user info in SQL , including their clear-text password .
Um , no .
All it takes is one rogue admin with the access to " Manage " that database , and suddenly they can pull the CEO 's password without anyone noticing , or a misconfigured SQL server running a non-ssl connection leaking that plain-text across the wire .
If you are properly implementing a two-factor system ( rsa securid or some equiv ) this isnt as big a deal , but still... no.Of course , lock down that SQL server like you 've never locked down anything before !
It should have a very limited interface for updating user data .
You should do this with any machine regardless .
Lock it down so only those that need it can get in , and they only have access to what needs to be worked on... standard policyNext , export user data to relevant external databases such as LDAP , NIS , SASL , that obscure sqlite app , Kerberos , DMZ services , etc , and you 'll have much less pain keeping everything in sync.Why ?
You end up with multiple copies of the same data spread across a multitude of disparate systems .
OpenLDAP plugs directly into SASL , Kerberos , Samba , Securid , FreeRadius and many other systems that are NOT really directories and therefore should not have the data themselves .
Instead they query LDAP for what they need , and LDAP is configured to let them read only what they need , securely ( access to attrs = BLAH by ssf = 128 dn.exact = " cn = someapp,dc = example,dc = com " read ) .
The ssl certs required are trivial to setup , just use CA.pl a few times , create a CA and a few test certs and you quickly get the hang of it .
Setting up LDAPS is generally easier than trying to make sure all your SQL connections are secure as well ( only start the ldaps service instead of ldap + ldaps , and use ssf = 128 for all acls ) .
With that in place , there is absolutely no risk of sending plain-text passwords in the clear over the wire , where your sql implementation seems ready and willing to do exactly that.-T</tokentext>
<sentencetext>Yes, SQL.
If you keep your raw data in SQL, it is easy to export data to any format you might need now or in the future.
slapcat &gt; myldaptree.ldiff

Done.
You now have an Ldiff file that can be re-imported directly, or parsed quite easily, not sure why Exporting seems difficult?LDAP gets you a long way, but you will sooner or later end up with several apps that don't support it.
The result is horrible password sync hacks, multiple passwords per user, etc.
gssapi/SASL, or if its a horribly broken ap that doesnt do that either, its trivial to write an authorize/authenticate plugin for it, just about everything supports LDAP though, or  "AD" which is usually LDAP with the MS schema in mind that can be bent to use a normal LDAP directory instead.
Password sync (to get the broken NT4/LANMAN and KRB5 passwords) is as simple as compiling smbk5pwd (for openldap) and making sure the things allowed to change user passwords only use the passwd exop in LDAP, which pam and most other items that can allow that have an option for.
Its not a hack, though you do end up with several different hashes of the same thing, as intended, but you can thank MS and MIT for using their own standard for hashing instead of plug-in cryptos, and pushing that for use in certain standards (WPA2 and Kerberos) .The idea is to put raw user info in SQL, including their clear-text password.
Um, no.
All it takes is one rogue admin with the access to "Manage" that database, and suddenly they can pull the CEO's password without anyone noticing, or a misconfigured SQL server running a non-ssl connection leaking that plain-text across the wire.
If you are properly implementing a two-factor system (rsa securid or some equiv) this isnt as big a deal, but still... no.Of course, lock down that SQL server like you've never locked down anything before!
It should have a very limited interface for updating user data.
You should do this with any machine regardless.
Lock it down so only those that need it can get in, and they only have access to what needs to be worked on... standard policyNext, export user data to relevant external databases such as LDAP, NIS, SASL, that obscure sqlite app, Kerberos, DMZ services, etc, and you'll have much less pain keeping everything in sync.Why?
You end up with multiple copies of the same data spread across a multitude of disparate systems.
OpenLDAP plugs directly into SASL, Kerberos, Samba, Securid, FreeRadius and many other systems that are NOT really directories and therefore should not have the data themselves.
Instead they query LDAP for what they need, and LDAP is configured to let them read only what they need, securely (access to attrs=BLAH by ssf=128 dn.exact="cn=someapp,dc=example,dc=com" read).
The ssl certs required are trivial to setup, just use CA.pl a few times, create a CA and a few test certs and you quickly get the hang of it.
Setting up LDAPS is generally easier than trying to make sure all your SQL connections are secure as well (only start the ldaps service instead of ldap+ldaps, and use ssf=128 for all acls).
With that in place, there is absolutely no risk of sending plain-text passwords in the clear over the wire, where your sql implementation seems ready and willing to do exactly that.-T
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214365</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28228127</id>
	<title>Re:Novell.......no seriously</title>
	<author>Rysc</author>
	<datestamp>1244200140000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Second!</p><p>If you're not going with a F/OSS DS, eDirectory is the product to buy. By itself it's great, with Novell's other tools it's even better. And it supports Windows clients, so no trouble there. If you're thinking "A directory server is a directory server, AD is good enough"--DON'T think this. There is such as thing as better and eDir is it, vs. AD or OLDAP.</p></htmltext>
<tokenext>Second ! If you 're not going with a F/OSS DS , eDirectory is the product to buy .
By itself it 's great , with Novell 's other tools it 's even better .
And it supports Windows clients , so no trouble there .
If you 're thinking " A directory server is a directory server , AD is good enough " --DO N'T think this .
There is such as thing as better and eDir is it , vs. AD or OLDAP .</tokentext>
<sentencetext>Second!If you're not going with a F/OSS DS, eDirectory is the product to buy.
By itself it's great, with Novell's other tools it's even better.
And it supports Windows clients, so no trouble there.
If you're thinking "A directory server is a directory server, AD is good enough"--DON'T think this.
There is such as thing as better and eDir is it, vs. AD or OLDAP.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213799</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214343</id>
	<title>Re:Easy</title>
	<author>Savage-Rabbit</author>
	<datestamp>1244106660000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p><div class="quote"><p>Use AD.<br>Even though folks will fuss and whine about AD being not pure LDAP...</p></div><p>You're not a developer, are you? Whether or not AD is a dream to work with depends heavily on what your job description is. If you are simply an administrator plugging random Windows or even Linux and *nix boxes into AD you might find it comparatively easy. If on the other hand you expect to have to develop custom applications of your own on non-Microsoft platforms that authenticate against AD or convert existing ones to use AD then it can be a painful experience to use AD. It's not an unsolvable problem mind you, just a really annoying one.</p><p><nobr> <wbr></nobr></p><div class="quote"><p>... It's simple enough that MCSEs can run it.</p></div><p>So is RHDS / Fedora Directory Server. I knew exactly nothing about LDAP or directory servers when I got my first directory server related project years ago. I still I got the thing set up and running inside of a couple of hours. Even an MCSE should be able to manage setting it up, hardening it and administrating it in a very short period of time.</p></div>
	</htmltext>
<tokenext>Use AD.Even though folks will fuss and whine about AD being not pure LDAP...You 're not a developer , are you ?
Whether or not AD is a dream to work with depends heavily on what your job description is .
If you are simply an administrator plugging random Windows or even Linux and * nix boxes into AD you might find it comparatively easy .
If on the other hand you expect to have to develop custom applications of your own on non-Microsoft platforms that authenticate against AD or convert existing ones to use AD then it can be a painful experience to use AD .
It 's not an unsolvable problem mind you , just a really annoying one .
... It 's simple enough that MCSEs can run it.So is RHDS / Fedora Directory Server .
I knew exactly nothing about LDAP or directory servers when I got my first directory server related project years ago .
I still I got the thing set up and running inside of a couple of hours .
Even an MCSE should be able to manage setting it up , hardening it and administrating it in a very short period of time .</tokentext>
<sentencetext>Use AD.Even though folks will fuss and whine about AD being not pure LDAP...You're not a developer, are you?
Whether or not AD is a dream to work with depends heavily on what your job description is.
If you are simply an administrator plugging random Windows or even Linux and *nix boxes into AD you might find it comparatively easy.
If on the other hand you expect to have to develop custom applications of your own on non-Microsoft platforms that authenticate against AD or convert existing ones to use AD then it can be a painful experience to use AD.
It's not an unsolvable problem mind you, just a really annoying one.
... It's simple enough that MCSEs can run it.So is RHDS / Fedora Directory Server.
I knew exactly nothing about LDAP or directory servers when I got my first directory server related project years ago.
I still I got the thing set up and running inside of a couple of hours.
Even an MCSE should be able to manage setting it up, hardening it and administrating it in a very short period of time.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213723</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213799</id>
	<title>Novell.......no seriously</title>
	<author>Anonymous</author>
	<datestamp>1244147580000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext>use Novell's eDirectory, it may cost, but they have a product called "Identity Manager" which allows you to interconnect many different systems to a central ID vault. Password changes are transparent, and management is extremely easy. Best of all it runs on Linux. You don't need the "netware" component to use it. It scales like a dream and is very robust</htmltext>
<tokenext>use Novell 's eDirectory , it may cost , but they have a product called " Identity Manager " which allows you to interconnect many different systems to a central ID vault .
Password changes are transparent , and management is extremely easy .
Best of all it runs on Linux .
You do n't need the " netware " component to use it .
It scales like a dream and is very robust</tokentext>
<sentencetext>use Novell's eDirectory, it may cost, but they have a product called "Identity Manager" which allows you to interconnect many different systems to a central ID vault.
Password changes are transparent, and management is extremely easy.
Best of all it runs on Linux.
You don't need the "netware" component to use it.
It scales like a dream and is very robust</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28217059</id>
	<title>No AD for me thanks.</title>
	<author>jvillain</author>
	<datestamp>1244121900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>In a high availability situation I would never trust AD to work with my nix machines. All it takes is Microsoft to make one change in the code and an admin to apply a patch to the AD servers and your nix machines can all be sitting their twittling their thumbs. Then you are stuck hoping that Microsoft wants to fix the problem. Mean while management will be sitting their blaming your nix machines and thinking it is better to go all windows.  If your shop wants to go all windows do it based on a buisness requirement not based on getting bent by microsoft yet again.</p></htmltext>
<tokenext>In a high availability situation I would never trust AD to work with my nix machines .
All it takes is Microsoft to make one change in the code and an admin to apply a patch to the AD servers and your nix machines can all be sitting their twittling their thumbs .
Then you are stuck hoping that Microsoft wants to fix the problem .
Mean while management will be sitting their blaming your nix machines and thinking it is better to go all windows .
If your shop wants to go all windows do it based on a buisness requirement not based on getting bent by microsoft yet again .</tokentext>
<sentencetext>In a high availability situation I would never trust AD to work with my nix machines.
All it takes is Microsoft to make one change in the code and an admin to apply a patch to the AD servers and your nix machines can all be sitting their twittling their thumbs.
Then you are stuck hoping that Microsoft wants to fix the problem.
Mean while management will be sitting their blaming your nix machines and thinking it is better to go all windows.
If your shop wants to go all windows do it based on a buisness requirement not based on getting bent by microsoft yet again.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214931</id>
	<title>NOT AD because of hidden complexity.</title>
	<author>xzvf</author>
	<datestamp>1244109720000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>The Linux/Unix world has done a great job making AD work in their world.  Just like we can read mail off an Exchange server and use Sharepoint.  They are easy on day one, but like most products from MS, there are a million hidden costs as you grow and expand.  If you start with a standards based LDAP directory server like 389-ds (Fedora-ds new name) you can grow into RHDS if you need support.  It is cheaper than AD as your environment grows plus if you decide to migrate to another DS, it is reasonably easy because it implemented an open standard.  Don't fall into the trap like so many did with Exchange and so many are with Sharepoint.</htmltext>
<tokenext>The Linux/Unix world has done a great job making AD work in their world .
Just like we can read mail off an Exchange server and use Sharepoint .
They are easy on day one , but like most products from MS , there are a million hidden costs as you grow and expand .
If you start with a standards based LDAP directory server like 389-ds ( Fedora-ds new name ) you can grow into RHDS if you need support .
It is cheaper than AD as your environment grows plus if you decide to migrate to another DS , it is reasonably easy because it implemented an open standard .
Do n't fall into the trap like so many did with Exchange and so many are with Sharepoint .</tokentext>
<sentencetext>The Linux/Unix world has done a great job making AD work in their world.
Just like we can read mail off an Exchange server and use Sharepoint.
They are easy on day one, but like most products from MS, there are a million hidden costs as you grow and expand.
If you start with a standards based LDAP directory server like 389-ds (Fedora-ds new name) you can grow into RHDS if you need support.
It is cheaper than AD as your environment grows plus if you decide to migrate to another DS, it is reasonably easy because it implemented an open standard.
Don't fall into the trap like so many did with Exchange and so many are with Sharepoint.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213723</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28217781</id>
	<title>The comments are interesting</title>
	<author>GF678</author>
	<datestamp>1244129340000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I notice that whenever someone recommends sticking with Active Directory, they apologies for recommending it.</p><p>It's amusing because they're apologizing for recommending the best solution in this situation, which is EXACTLY what a good commenter should do. They have nothing to apologize for, and so I guess their apologies are more for the fanboys than anyone else who cares about a good result.</p><p>Just admit it - OSS doesn't always work, so making a suggestion which involves using Microsoft technologies is nothing to be ashamed of. It shows you aren't an idiot and prefer the best solution as opposed to a Slashdot friendly solution.</p></htmltext>
<tokenext>I notice that whenever someone recommends sticking with Active Directory , they apologies for recommending it.It 's amusing because they 're apologizing for recommending the best solution in this situation , which is EXACTLY what a good commenter should do .
They have nothing to apologize for , and so I guess their apologies are more for the fanboys than anyone else who cares about a good result.Just admit it - OSS does n't always work , so making a suggestion which involves using Microsoft technologies is nothing to be ashamed of .
It shows you are n't an idiot and prefer the best solution as opposed to a Slashdot friendly solution .</tokentext>
<sentencetext>I notice that whenever someone recommends sticking with Active Directory, they apologies for recommending it.It's amusing because they're apologizing for recommending the best solution in this situation, which is EXACTLY what a good commenter should do.
They have nothing to apologize for, and so I guess their apologies are more for the fanboys than anyone else who cares about a good result.Just admit it - OSS doesn't always work, so making a suggestion which involves using Microsoft technologies is nothing to be ashamed of.
It shows you aren't an idiot and prefer the best solution as opposed to a Slashdot friendly solution.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28223093</id>
	<title>What About Sun One?</title>
	<author>Anonymous</author>
	<datestamp>1244219340000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>... aka DSSE, etc. - see http://www.sun.com/software/products/directory\_srvr\_ee/index.jsp</p><p>I don't know - just asking. It's free-as-in-beer, you can (presumably) buy support from SunOracle.</p><p>Discuss.</p></htmltext>
<tokenext>... aka DSSE , etc .
- see http : //www.sun.com/software/products/directory \ _srvr \ _ee/index.jspI do n't know - just asking .
It 's free-as-in-beer , you can ( presumably ) buy support from SunOracle.Discuss .</tokentext>
<sentencetext>... aka DSSE, etc.
- see http://www.sun.com/software/products/directory\_srvr\_ee/index.jspI don't know - just asking.
It's free-as-in-beer, you can (presumably) buy support from SunOracle.Discuss.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213751</id>
	<title>First Post :-)</title>
	<author>Anonymous</author>
	<datestamp>1244147400000</datestamp>
	<modclass>Flamebait</modclass>
	<modscore>-1</modscore>
	<htmltext>Anyway, I would recommend using Linux for the actual power behind your network, and maybe use Windows as interface workstations (because Windows sucks for anything needing stability). Think of it this way: You're using Windows as the control panel for a Linux-based supercomputer.</htmltext>
<tokenext>Anyway , I would recommend using Linux for the actual power behind your network , and maybe use Windows as interface workstations ( because Windows sucks for anything needing stability ) .
Think of it this way : You 're using Windows as the control panel for a Linux-based supercomputer .</tokentext>
<sentencetext>Anyway, I would recommend using Linux for the actual power behind your network, and maybe use Windows as interface workstations (because Windows sucks for anything needing stability).
Think of it this way: You're using Windows as the control panel for a Linux-based supercomputer.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214595</id>
	<title>Re:Easy</title>
	<author>Anonymous</author>
	<datestamp>1244108160000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>1</modscore>
	<htmltext><p>The problem with AD is lock-in. Once you deploy AD, you will <i>never</i> be able to switch to another directory product, as Microsoft software dependency creep will ensure that no other product can operate as a drop-in replacement.</p><p>If you only have a few Windows machines, use a standardized solution and live with loss of MS-specific functionality. If you deploy AD, you'll soon find yourself locked in, and the investment in MS-only technology will only keep growing.</p></htmltext>
<tokenext>The problem with AD is lock-in .
Once you deploy AD , you will never be able to switch to another directory product , as Microsoft software dependency creep will ensure that no other product can operate as a drop-in replacement.If you only have a few Windows machines , use a standardized solution and live with loss of MS-specific functionality .
If you deploy AD , you 'll soon find yourself locked in , and the investment in MS-only technology will only keep growing .</tokentext>
<sentencetext>The problem with AD is lock-in.
Once you deploy AD, you will never be able to switch to another directory product, as Microsoft software dependency creep will ensure that no other product can operate as a drop-in replacement.If you only have a few Windows machines, use a standardized solution and live with loss of MS-specific functionality.
If you deploy AD, you'll soon find yourself locked in, and the investment in MS-only technology will only keep growing.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213723</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28217383</id>
	<title>Why not Apple's Open Directory</title>
	<author>Anonymous</author>
	<datestamp>1244124480000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>With the mostly Linux/UNIX boxes and only few Windows boxes Apple's OS X Servers Open Directory (openLDAP/Kerberos) is very easy to use, and with less than 8 clicks you can have SAMBA configured with it to authenticate the Windows boxes.  All clients would use Kerberos for authentication, plus you are using open source technology.</p><p>Depends on what control you want over the Windows boxes.</p><p>Linux/Mac/Windows Admin</p></htmltext>
<tokenext>With the mostly Linux/UNIX boxes and only few Windows boxes Apple 's OS X Servers Open Directory ( openLDAP/Kerberos ) is very easy to use , and with less than 8 clicks you can have SAMBA configured with it to authenticate the Windows boxes .
All clients would use Kerberos for authentication , plus you are using open source technology.Depends on what control you want over the Windows boxes.Linux/Mac/Windows Admin</tokentext>
<sentencetext>With the mostly Linux/UNIX boxes and only few Windows boxes Apple's OS X Servers Open Directory (openLDAP/Kerberos) is very easy to use, and with less than 8 clicks you can have SAMBA configured with it to authenticate the Windows boxes.
All clients would use Kerberos for authentication, plus you are using open source technology.Depends on what control you want over the Windows boxes.Linux/Mac/Windows Admin</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28219235</id>
	<title>Stay with AD? why can't you use a legacy unix app?</title>
	<author>cobradevil</author>
	<datestamp>1244232960000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Hello all

At our company we have a big AD domain with 35 domain controllers. When AD was introduced we had o disable our unix dns server because windows comes with everything in it. So yes we build a few data centers with AD. Now we are also running a few hundred linux systems for SAP. We had to connect to AD because we already have that. So we were connecting our systems to  AD with winbind and now it seems wibindd can't handle the load.
People can't login so we have to trouble shoot that.When asking our AD guru's the only answer you get is everything is working fine<nobr> <wbr></nobr>;()())&amp;@\%$#... Now we are going to only use the kerberos stack from AD in the AD domain, and authorizations will be done in our own directory. For other environments where we haven't got AD we are going to use our own kerberos/directory domain. The next step will be a solution like freeipa because why shouldn't we use our own native authentication services. Radius and LDAP have been used for years and are proven technology's. Kerberos can be used for authentication and bind 9.5 also supports gssapi to do ddns updates. So disable those windows ddns and stay at the save side before you can't disconnect your systems from AD because it is the defacto non standard. Use open software for your open servers. And let windows use their own directory services. Also you can use windows password sync for project 389 if you wanna have password synchronization.

People before you know you can't get rid of AD anymore and you are forced to buy MS products. Check out zimbra for email and use apache for web aplications it's not hard and the performance is great.

A unix researcher;)</htmltext>
<tokenext>Hello all At our company we have a big AD domain with 35 domain controllers .
When AD was introduced we had o disable our unix dns server because windows comes with everything in it .
So yes we build a few data centers with AD .
Now we are also running a few hundred linux systems for SAP .
We had to connect to AD because we already have that .
So we were connecting our systems to AD with winbind and now it seems wibindd ca n't handle the load .
People ca n't login so we have to trouble shoot that.When asking our AD guru 's the only answer you get is everything is working fine ; ( ) ( ) ) &amp; @ \ % $ # ... Now we are going to only use the kerberos stack from AD in the AD domain , and authorizations will be done in our own directory .
For other environments where we have n't got AD we are going to use our own kerberos/directory domain .
The next step will be a solution like freeipa because why should n't we use our own native authentication services .
Radius and LDAP have been used for years and are proven technology 's .
Kerberos can be used for authentication and bind 9.5 also supports gssapi to do ddns updates .
So disable those windows ddns and stay at the save side before you ca n't disconnect your systems from AD because it is the defacto non standard .
Use open software for your open servers .
And let windows use their own directory services .
Also you can use windows password sync for project 389 if you wan na have password synchronization .
People before you know you ca n't get rid of AD anymore and you are forced to buy MS products .
Check out zimbra for email and use apache for web aplications it 's not hard and the performance is great .
A unix researcher ; )</tokentext>
<sentencetext>Hello all

At our company we have a big AD domain with 35 domain controllers.
When AD was introduced we had o disable our unix dns server because windows comes with everything in it.
So yes we build a few data centers with AD.
Now we are also running a few hundred linux systems for SAP.
We had to connect to AD because we already have that.
So we were connecting our systems to  AD with winbind and now it seems wibindd can't handle the load.
People can't login so we have to trouble shoot that.When asking our AD guru's the only answer you get is everything is working fine ;()())&amp;@\%$#... Now we are going to only use the kerberos stack from AD in the AD domain, and authorizations will be done in our own directory.
For other environments where we haven't got AD we are going to use our own kerberos/directory domain.
The next step will be a solution like freeipa because why shouldn't we use our own native authentication services.
Radius and LDAP have been used for years and are proven technology's.
Kerberos can be used for authentication and bind 9.5 also supports gssapi to do ddns updates.
So disable those windows ddns and stay at the save side before you can't disconnect your systems from AD because it is the defacto non standard.
Use open software for your open servers.
And let windows use their own directory services.
Also you can use windows password sync for project 389 if you wanna have password synchronization.
People before you know you can't get rid of AD anymore and you are forced to buy MS products.
Check out zimbra for email and use apache for web aplications it's not hard and the performance is great.
A unix researcher;)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28217189</id>
	<title>eDirectory</title>
	<author>Anonymous</author>
	<datestamp>1244122920000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I'd rate your best option, by far, is eDirectory</p><p>Fully LDAP Compliant.<br>Can handle your directory regardless of how large it gets (AD STILL has scaling issues)<br>Can remap all the default mappings for both attributes and classes so you could very easily have your eDirectory tree replicate the behaviour of everything from AD-LDAP to OpenLDAP<br>Latest eDirectory services on OES 2 SP1 include Domain Services for Windows, allowing *native* AD calls to work (you can even manage your eDirectory with MMC)</p><p>And if you ever find eDirectory can't do everything you want it to, you can always use Identity Manger to sync your eDirectory to practically any other service you're using.</p><p>Sure, AD is great, if you're a total Microsoft house, but you'll have nothing but issues trying to get it to play nice with your Linux kit, and if you get yourself near 15,000 users you'll be wishing you had a system that scaled.<br>OpenLDAP is great, if you're a total non-Microsoft house, but you'll have nothing but issues trying to get it to play nice with your MS kit, and if you might find some of its feature set limiting.</p></htmltext>
<tokenext>I 'd rate your best option , by far , is eDirectoryFully LDAP Compliant.Can handle your directory regardless of how large it gets ( AD STILL has scaling issues ) Can remap all the default mappings for both attributes and classes so you could very easily have your eDirectory tree replicate the behaviour of everything from AD-LDAP to OpenLDAPLatest eDirectory services on OES 2 SP1 include Domain Services for Windows , allowing * native * AD calls to work ( you can even manage your eDirectory with MMC ) And if you ever find eDirectory ca n't do everything you want it to , you can always use Identity Manger to sync your eDirectory to practically any other service you 're using.Sure , AD is great , if you 're a total Microsoft house , but you 'll have nothing but issues trying to get it to play nice with your Linux kit , and if you get yourself near 15,000 users you 'll be wishing you had a system that scaled.OpenLDAP is great , if you 're a total non-Microsoft house , but you 'll have nothing but issues trying to get it to play nice with your MS kit , and if you might find some of its feature set limiting .</tokentext>
<sentencetext>I'd rate your best option, by far, is eDirectoryFully LDAP Compliant.Can handle your directory regardless of how large it gets (AD STILL has scaling issues)Can remap all the default mappings for both attributes and classes so you could very easily have your eDirectory tree replicate the behaviour of everything from AD-LDAP to OpenLDAPLatest eDirectory services on OES 2 SP1 include Domain Services for Windows, allowing *native* AD calls to work (you can even manage your eDirectory with MMC)And if you ever find eDirectory can't do everything you want it to, you can always use Identity Manger to sync your eDirectory to practically any other service you're using.Sure, AD is great, if you're a total Microsoft house, but you'll have nothing but issues trying to get it to play nice with your Linux kit, and if you get yourself near 15,000 users you'll be wishing you had a system that scaled.OpenLDAP is great, if you're a total non-Microsoft house, but you'll have nothing but issues trying to get it to play nice with your MS kit, and if you might find some of its feature set limiting.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214011</id>
	<title>AD</title>
	<author>Malenx</author>
	<datestamp>1244148360000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>Microsoft has really done well with developing AD.</p><p>It's just honestly the best product out there currently.</p></htmltext>
<tokenext>Microsoft has really done well with developing AD.It 's just honestly the best product out there currently .</tokentext>
<sentencetext>Microsoft has really done well with developing AD.It's just honestly the best product out there currently.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28217883</id>
	<title>Directory services</title>
	<author>dlawson</author>
	<datestamp>1244130480000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>   I have a pretty long history of this, and I have set up a couple of major implementations (1,000,000+ objects) so I'm putting in my 2cents.</p><p>
&nbsp; &nbsp; &nbsp; I started with Novell's NDS in 1993 (yup, I was a beta tester) and so I am pretty oriented towards that product. Other Directory Service products I have managed include AD and eTrust. I am still most impressed with Novell's product, and for good reasons. AD is really an LDAP interface into a distributed registry. It is not really a full  X.500 directory, and it weaknesses show when it comes time to upgrade or migrate. eTrust is built on the old Ingres database (Alan Lloyd couldn't get a free copy of Oracle) and there were issues with it's replication and failover modes when I ran it. Once burned, twice shy. The most reliable, in terms of not getting up at 2 AM, was eDirectory, and I still respect Novell's attitude towards Quality.</p><p>
&nbsp; &nbsp; &nbsp; The performance of most DS products is pretty equal these days, a test I read last year had a 4-core Opteron doing 60,000+ searches per second. That's plenty, divide the number of leaf objects by that number to find the number of processors you will need. More importantly is how you build your tree, and that is NOT a minor effort. Number one, you will need replicas, at least three of each partition in the tree. Number two, enough bandwidth to make sure that replication and synchronization is not impeded. Number three, you WILL have a number of arguments from the management team (if they are one) at the normal number of communication paths within the team, that is N! if they all fight separately, N!/P! if they gang up. These arguments will be centered on who has what access, up to why the tree doesn't place them at the top (hint: follow the organization chart. Get the CEO to tell HR to give it to you.)</p><p>
&nbsp; &nbsp; &nbsp; After that, it's really a matter of studying the available literature. Get a copy of the X.500 documentation to understand the standards for update and replication, and after that, try a couple of test implementations in a little three server lab. You can probably do that on a couple of one-lung PCs to get a feel for what the tree will look like and how to manage it. I haven't had a test lab in my house in a couple of years, but the last one was an Athlon laptop with OES 1 on it. Get a copy of NDS Basics from Novell Press and bone up. The other book useful to this effort is Open Enterprise Server Administrator's Handbook also from Novell Press. Grab an eval copy of OES and practice. When you go live, the price of the eDirectory component itself is worth the cost of OES.<br>davel</p></htmltext>
<tokenext>I have a pretty long history of this , and I have set up a couple of major implementations ( 1,000,000 + objects ) so I 'm putting in my 2cents .
      I started with Novell 's NDS in 1993 ( yup , I was a beta tester ) and so I am pretty oriented towards that product .
Other Directory Service products I have managed include AD and eTrust .
I am still most impressed with Novell 's product , and for good reasons .
AD is really an LDAP interface into a distributed registry .
It is not really a full X.500 directory , and it weaknesses show when it comes time to upgrade or migrate .
eTrust is built on the old Ingres database ( Alan Lloyd could n't get a free copy of Oracle ) and there were issues with it 's replication and failover modes when I ran it .
Once burned , twice shy .
The most reliable , in terms of not getting up at 2 AM , was eDirectory , and I still respect Novell 's attitude towards Quality .
      The performance of most DS products is pretty equal these days , a test I read last year had a 4-core Opteron doing 60,000 + searches per second .
That 's plenty , divide the number of leaf objects by that number to find the number of processors you will need .
More importantly is how you build your tree , and that is NOT a minor effort .
Number one , you will need replicas , at least three of each partition in the tree .
Number two , enough bandwidth to make sure that replication and synchronization is not impeded .
Number three , you WILL have a number of arguments from the management team ( if they are one ) at the normal number of communication paths within the team , that is N !
if they all fight separately , N ! /P !
if they gang up .
These arguments will be centered on who has what access , up to why the tree does n't place them at the top ( hint : follow the organization chart .
Get the CEO to tell HR to give it to you .
)       After that , it 's really a matter of studying the available literature .
Get a copy of the X.500 documentation to understand the standards for update and replication , and after that , try a couple of test implementations in a little three server lab .
You can probably do that on a couple of one-lung PCs to get a feel for what the tree will look like and how to manage it .
I have n't had a test lab in my house in a couple of years , but the last one was an Athlon laptop with OES 1 on it .
Get a copy of NDS Basics from Novell Press and bone up .
The other book useful to this effort is Open Enterprise Server Administrator 's Handbook also from Novell Press .
Grab an eval copy of OES and practice .
When you go live , the price of the eDirectory component itself is worth the cost of OES.davel</tokentext>
<sentencetext>   I have a pretty long history of this, and I have set up a couple of major implementations (1,000,000+ objects) so I'm putting in my 2cents.
      I started with Novell's NDS in 1993 (yup, I was a beta tester) and so I am pretty oriented towards that product.
Other Directory Service products I have managed include AD and eTrust.
I am still most impressed with Novell's product, and for good reasons.
AD is really an LDAP interface into a distributed registry.
It is not really a full  X.500 directory, and it weaknesses show when it comes time to upgrade or migrate.
eTrust is built on the old Ingres database (Alan Lloyd couldn't get a free copy of Oracle) and there were issues with it's replication and failover modes when I ran it.
Once burned, twice shy.
The most reliable, in terms of not getting up at 2 AM, was eDirectory, and I still respect Novell's attitude towards Quality.
      The performance of most DS products is pretty equal these days, a test I read last year had a 4-core Opteron doing 60,000+ searches per second.
That's plenty, divide the number of leaf objects by that number to find the number of processors you will need.
More importantly is how you build your tree, and that is NOT a minor effort.
Number one, you will need replicas, at least three of each partition in the tree.
Number two, enough bandwidth to make sure that replication and synchronization is not impeded.
Number three, you WILL have a number of arguments from the management team (if they are one) at the normal number of communication paths within the team, that is N!
if they all fight separately, N!/P!
if they gang up.
These arguments will be centered on who has what access, up to why the tree doesn't place them at the top (hint: follow the organization chart.
Get the CEO to tell HR to give it to you.
)
      After that, it's really a matter of studying the available literature.
Get a copy of the X.500 documentation to understand the standards for update and replication, and after that, try a couple of test implementations in a little three server lab.
You can probably do that on a couple of one-lung PCs to get a feel for what the tree will look like and how to manage it.
I haven't had a test lab in my house in a couple of years, but the last one was an Athlon laptop with OES 1 on it.
Get a copy of NDS Basics from Novell Press and bone up.
The other book useful to this effort is Open Enterprise Server Administrator's Handbook also from Novell Press.
Grab an eval copy of OES and practice.
When you go live, the price of the eDirectory component itself is worth the cost of OES.davel</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28218331</id>
	<title>mac os x server</title>
	<author>Anonymous</author>
	<datestamp>1244135340000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>open directory<nobr> <wbr></nobr>... http://www.apple.com/server/macosx/technology/opendirectory.html plug it in, turn it on, and it works. only downside is that you are limited to apple hardware.</p></htmltext>
<tokenext>open directory ... http : //www.apple.com/server/macosx/technology/opendirectory.html plug it in , turn it on , and it works .
only downside is that you are limited to apple hardware .</tokentext>
<sentencetext>open directory ... http://www.apple.com/server/macosx/technology/opendirectory.html plug it in, turn it on, and it works.
only downside is that you are limited to apple hardware.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28217673</id>
	<title>Re:Easy</title>
	<author>Anonymous</author>
	<datestamp>1244127840000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>Authenticating against AD is hard?  I didn't realize that, I mean, I've been writing apps that authenticate against kerberos since before AD existed, and since those same apps authenticate against ActiveDirectory the exact same way, I must have missed the hard part.</p><p>Hard to authenticate against AD, WTF are you talking about?  Do you know how it even works?  If you're using some retarded fucking bind against ldap for verifying authentication to your apps?  If you use the bind to allow the user to authenticate and authorize like a standard user to the ldap server thats one thing, but if you're pulling some bullshit like using an ldap auth to allow them into your webapp which stores everything in a mysql database than you need to be took out and shot.  You use kerberos to authenticate and the directory to pull user DIRECTORY type information out of, you know, uid/gid/homedir/name/emailaddress.  I highly expect that you don't understand what directories are for and how to properly use them.</p><p>So lets even assume you're trying to be an idiot and do an auth using an ldap bind.  Its different how?  Because an out of the box server expects working SSL for authenticating?  Considering openldaps utilities will bind to AD just as well as they will to an openldap server I think you might want to consider switching to a ldap library that doesn't suck ass.  Try openldap as a start, it works flawlessly with ActiveDirectory.</p><p>Are you bitching about Schema?  I hope not, cause if your schema expectations are hard coded into the application than you're only going to work on ONE server type, since no one shares the same default schema for the same attributes.</p><p>I'm not really sure what your problem was since you didn't specify, but you have to write a pretty shitty app if you have problems using ActiveDirectory server with it, and its a safe bet your apps will only work against one specific ldap schema if thats the case.</p><p>I'm not sure how easy it is with RHDS, but installing AD is rather trivial if you can click 'Next' several times in a row and enter a little info in some text boxes.  How well does kerberos work after an out of the box RHDS install?  I wasn't aware that it included kerberos support?  Kerberos is the PROPER way to authenticate clients you know, not binding to the server with clear text passwords.</p><p>Don't get me wrong, I'm not knocking OpenLDAP, or any other implementation.  I'm a big fan of OpenLDAP, but if you have a problem connecting and working with the ActiveDirectory LDAP service, you fucked up, likely not it.  The only exception to this I can see is that you're doing something rather complex that has specific sorts of support or ADS doesn't implement (standard or otherwise) due to its obscurity.  Either way, you're probably having issues working with servers other than AD.  LDAP may be a standard, but so is HTML, no one has the perfect implementation.</p><p>Stop hating, AD may be from MS, but its actually not shitty.  Credit where credit is due.</p></htmltext>
<tokenext>Authenticating against AD is hard ?
I did n't realize that , I mean , I 've been writing apps that authenticate against kerberos since before AD existed , and since those same apps authenticate against ActiveDirectory the exact same way , I must have missed the hard part.Hard to authenticate against AD , WTF are you talking about ?
Do you know how it even works ?
If you 're using some retarded fucking bind against ldap for verifying authentication to your apps ?
If you use the bind to allow the user to authenticate and authorize like a standard user to the ldap server thats one thing , but if you 're pulling some bullshit like using an ldap auth to allow them into your webapp which stores everything in a mysql database than you need to be took out and shot .
You use kerberos to authenticate and the directory to pull user DIRECTORY type information out of , you know , uid/gid/homedir/name/emailaddress .
I highly expect that you do n't understand what directories are for and how to properly use them.So lets even assume you 're trying to be an idiot and do an auth using an ldap bind .
Its different how ?
Because an out of the box server expects working SSL for authenticating ?
Considering openldaps utilities will bind to AD just as well as they will to an openldap server I think you might want to consider switching to a ldap library that does n't suck ass .
Try openldap as a start , it works flawlessly with ActiveDirectory.Are you bitching about Schema ?
I hope not , cause if your schema expectations are hard coded into the application than you 're only going to work on ONE server type , since no one shares the same default schema for the same attributes.I 'm not really sure what your problem was since you did n't specify , but you have to write a pretty shitty app if you have problems using ActiveDirectory server with it , and its a safe bet your apps will only work against one specific ldap schema if thats the case.I 'm not sure how easy it is with RHDS , but installing AD is rather trivial if you can click 'Next ' several times in a row and enter a little info in some text boxes .
How well does kerberos work after an out of the box RHDS install ?
I was n't aware that it included kerberos support ?
Kerberos is the PROPER way to authenticate clients you know , not binding to the server with clear text passwords.Do n't get me wrong , I 'm not knocking OpenLDAP , or any other implementation .
I 'm a big fan of OpenLDAP , but if you have a problem connecting and working with the ActiveDirectory LDAP service , you fucked up , likely not it .
The only exception to this I can see is that you 're doing something rather complex that has specific sorts of support or ADS does n't implement ( standard or otherwise ) due to its obscurity .
Either way , you 're probably having issues working with servers other than AD .
LDAP may be a standard , but so is HTML , no one has the perfect implementation.Stop hating , AD may be from MS , but its actually not shitty .
Credit where credit is due .</tokentext>
<sentencetext>Authenticating against AD is hard?
I didn't realize that, I mean, I've been writing apps that authenticate against kerberos since before AD existed, and since those same apps authenticate against ActiveDirectory the exact same way, I must have missed the hard part.Hard to authenticate against AD, WTF are you talking about?
Do you know how it even works?
If you're using some retarded fucking bind against ldap for verifying authentication to your apps?
If you use the bind to allow the user to authenticate and authorize like a standard user to the ldap server thats one thing, but if you're pulling some bullshit like using an ldap auth to allow them into your webapp which stores everything in a mysql database than you need to be took out and shot.
You use kerberos to authenticate and the directory to pull user DIRECTORY type information out of, you know, uid/gid/homedir/name/emailaddress.
I highly expect that you don't understand what directories are for and how to properly use them.So lets even assume you're trying to be an idiot and do an auth using an ldap bind.
Its different how?
Because an out of the box server expects working SSL for authenticating?
Considering openldaps utilities will bind to AD just as well as they will to an openldap server I think you might want to consider switching to a ldap library that doesn't suck ass.
Try openldap as a start, it works flawlessly with ActiveDirectory.Are you bitching about Schema?
I hope not, cause if your schema expectations are hard coded into the application than you're only going to work on ONE server type, since no one shares the same default schema for the same attributes.I'm not really sure what your problem was since you didn't specify, but you have to write a pretty shitty app if you have problems using ActiveDirectory server with it, and its a safe bet your apps will only work against one specific ldap schema if thats the case.I'm not sure how easy it is with RHDS, but installing AD is rather trivial if you can click 'Next' several times in a row and enter a little info in some text boxes.
How well does kerberos work after an out of the box RHDS install?
I wasn't aware that it included kerberos support?
Kerberos is the PROPER way to authenticate clients you know, not binding to the server with clear text passwords.Don't get me wrong, I'm not knocking OpenLDAP, or any other implementation.
I'm a big fan of OpenLDAP, but if you have a problem connecting and working with the ActiveDirectory LDAP service, you fucked up, likely not it.
The only exception to this I can see is that you're doing something rather complex that has specific sorts of support or ADS doesn't implement (standard or otherwise) due to its obscurity.
Either way, you're probably having issues working with servers other than AD.
LDAP may be a standard, but so is HTML, no one has the perfect implementation.Stop hating, AD may be from MS, but its actually not shitty.
Credit where credit is due.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214343</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28282997</id>
	<title>Anonymous Coward</title>
	<author>Anonymous</author>
	<datestamp>1244662320000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>eDir is hands down the most sophisticated directory platform on the planet. It beats AD's flat file any day of the week. It runs on Windows, Unix, Solaris, and Linux. Most of the troubleshooting and setup documentation can be accessed for free, and without creating huge, distributed, complicated setups, runs problem free as well.</p><p>With the latest version, an eDir box can belong to an AD domain, or an eDirectory tree. Without support, eDir can be had for free.</p></htmltext>
<tokenext>eDir is hands down the most sophisticated directory platform on the planet .
It beats AD 's flat file any day of the week .
It runs on Windows , Unix , Solaris , and Linux .
Most of the troubleshooting and setup documentation can be accessed for free , and without creating huge , distributed , complicated setups , runs problem free as well.With the latest version , an eDir box can belong to an AD domain , or an eDirectory tree .
Without support , eDir can be had for free .</tokentext>
<sentencetext>eDir is hands down the most sophisticated directory platform on the planet.
It beats AD's flat file any day of the week.
It runs on Windows, Unix, Solaris, and Linux.
Most of the troubleshooting and setup documentation can be accessed for free, and without creating huge, distributed, complicated setups, runs problem free as well.With the latest version, an eDir box can belong to an AD domain, or an eDirectory tree.
Without support, eDir can be had for free.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214623</id>
	<title>try OS X server</title>
	<author>Anonymous</author>
	<datestamp>1244108340000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Depending on your size  you might want to consider Apple's OS X server product.</p><p>I am in the middle of building a new infrastructure based on open directory which is apple's version of LDAP.  so far I have the mac, linux and windows boxes authenticating against it, as well as postsql, drupal,</p><p>still working on fully setting it up, but so far so good.</p><p>It's replacing:<br>netscape old LDAP<br>Sun's NIS+<br>Redhat NIS<br>and Active directory</p><p>so in the long run it should be better than what we have now</p></htmltext>
<tokenext>Depending on your size you might want to consider Apple 's OS X server product.I am in the middle of building a new infrastructure based on open directory which is apple 's version of LDAP .
so far I have the mac , linux and windows boxes authenticating against it , as well as postsql , drupal,still working on fully setting it up , but so far so good.It 's replacing : netscape old LDAPSun 's NIS + Redhat NISand Active directoryso in the long run it should be better than what we have now</tokentext>
<sentencetext>Depending on your size  you might want to consider Apple's OS X server product.I am in the middle of building a new infrastructure based on open directory which is apple's version of LDAP.
so far I have the mac, linux and windows boxes authenticating against it, as well as postsql, drupal,still working on fully setting it up, but so far so good.It's replacing:netscape old LDAPSun's NIS+Redhat NISand Active directoryso in the long run it should be better than what we have now</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213757</id>
	<title>Just go with AD</title>
	<author>anom</author>
	<datestamp>1244147400000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext><p>I really hate to say it, but I think Active Directory is most definitely the way to go.  No other directory systems allows for as simple administration of a large number of windows computers, your windows clients will "Just Work" with it, and it isn't difficult to make windows boxes, wikis, etc authenticate against it (I've had to do this many times...).</p><p>Active directory lets you access it via LDAP which a lot of software packages understand (a note here, structure the LDAP binds such that the username is in the form of SAMACCOUNTNAME@WINDOWSDOMAINFQDN, this has worked almost every time for me).</p><p>The free version of Likewise Open will make it very easy for the linux boxes themselves to authenticate against AD without having to mess with any pam conf yourself, and if you pay them money you can even deploy GP's to linux boxes (disclaimer, I've never tried this part).</p><p>In sum, while I hate to say it, you can make almost any client solution work with AD either directly or via LDAP or Kerberos, and it's the best possible solution for windows client management, so I'd go with that.</p><p>Just my<nobr> <wbr></nobr>.02</p></htmltext>
<tokenext>I really hate to say it , but I think Active Directory is most definitely the way to go .
No other directory systems allows for as simple administration of a large number of windows computers , your windows clients will " Just Work " with it , and it is n't difficult to make windows boxes , wikis , etc authenticate against it ( I 've had to do this many times... ) .Active directory lets you access it via LDAP which a lot of software packages understand ( a note here , structure the LDAP binds such that the username is in the form of SAMACCOUNTNAME @ WINDOWSDOMAINFQDN , this has worked almost every time for me ) .The free version of Likewise Open will make it very easy for the linux boxes themselves to authenticate against AD without having to mess with any pam conf yourself , and if you pay them money you can even deploy GP 's to linux boxes ( disclaimer , I 've never tried this part ) .In sum , while I hate to say it , you can make almost any client solution work with AD either directly or via LDAP or Kerberos , and it 's the best possible solution for windows client management , so I 'd go with that.Just my .02</tokentext>
<sentencetext>I really hate to say it, but I think Active Directory is most definitely the way to go.
No other directory systems allows for as simple administration of a large number of windows computers, your windows clients will "Just Work" with it, and it isn't difficult to make windows boxes, wikis, etc authenticate against it (I've had to do this many times...).Active directory lets you access it via LDAP which a lot of software packages understand (a note here, structure the LDAP binds such that the username is in the form of SAMACCOUNTNAME@WINDOWSDOMAINFQDN, this has worked almost every time for me).The free version of Likewise Open will make it very easy for the linux boxes themselves to authenticate against AD without having to mess with any pam conf yourself, and if you pay them money you can even deploy GP's to linux boxes (disclaimer, I've never tried this part).In sum, while I hate to say it, you can make almost any client solution work with AD either directly or via LDAP or Kerberos, and it's the best possible solution for windows client management, so I'd go with that.Just my .02</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214727</id>
	<title>Hear me out</title>
	<author>Anonymous</author>
	<datestamp>1244108820000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>5</modscore>
	<htmltext><p>Its going to sound like blasphemy here on slashdot, but I strongly recommend one master ActiveDirectory server with Services for Unix installed.  You can manage everything from the nice pretty windows GUI, have perfect windows support and using pam\_krb5 and nss\_ldap (I use them in FreeBSD, I believe both of which were originally for linux, not sure they would be the best for it) for pulling all your user information from AD.  Services for UNIX adds tabs to the important objects in the ActiveDirectory UI to let you edit the unix attributes.</p><p>Combine nss\_ldap, pam\_krb5, sasl with kerberose auth, and samba 3 or newer, the kerberos auth module for Apache and you can have complete and total authentication based on ActiveDirectory with a very nice GUI, and you can still use standard ldap tools to work with the directory if you want.  Samba will do kerberos with windows beautifully at this point, just make sure you keep eveything time synced.  Even does all the 'single signon' stuff for websites.</p><p>You end up using a great authentication mechanism on your unix AND windows hosts (kerberos is king).  The only catch that may or may not apply to other OSes, but it definately bit me in FreeBSD 6, FBSD wants to use UDP for all its kerberos communications which is normally fine, but once you get a user with a large collection of kerberos data, in my case, lots of groups either directly or via nesting, then the packets become too large for a single UDP datagram and FBSD is too stupid to switch to TCP on its on.  My solution was simply to block all UDP port 88 requests in and out of my FBSD boxes so they immediately fail over to TCP (not, you have to return ICMP errors, not just drop packets or it'll just hang as it doesn't know the packet can't be sent).</p><p>Not sure if Linux's kerberos implementation supports forcing TCP in krb5.conf.  FreeBSD is SUPPOSED to, but older version certainly don't.</p><p>I know that no one likes MS and thinks they are evil, but I've been VERY happy using AD.  We have two Win2k3 machines that serves ActiveDirectory, basically a primary and backup domain controller in the old MS NTDOMAIN language.  Works awesome.  If you throw in the MS certificate server on your AD server, then you also have a nice way to make internal SSL certificates with full revokation support and all that neat stuff so you can make internal certs all day long and the  since your Windows machines are part of the ActiveDirectory, it pushes its root cert to all your windows boxes meaning you don't have to do crap to make them fully authenticated certs for your windows machines.</p><p>With far less effort than any other directory server you can have full single sign on support, good authentication, and an easy to use interface in which you can delegate control to various folks outside your IT department and let them use the AD manager for windows (on xp or whatever) to manage the department they need to if you want.  You can auth pretty much EVERY modern OS this way.  Hell if you want to you can run the servers on Unix (OpenLDAP/MIT Kerberos) for backup or for serving client requests and just isolate the windows machine as the master if you want.</p><p>Okay, now I sound like a total fanboy, please don't hate, but it really is a good setup.  The main reason being, from my point of view, the setup and most importantly, the administration of ActiveDirectory and Services for UNIX are FAR above and beyond anything the F/OSS world offers.  Sad, but true.  I imagine you could probably get good support from Novell eDirectory as its tools are pretty good when they work, haven't used them since 6.0 when all their Java apps were asstastic, but I was only admining the leaf node of a tree with a few hundred thousand accounts in it (State of Georgia was using eDirectory a few years back, all their employees are in it, may have changed by now), so it may work better in smaller setups.  All things considered it didn't do bad there, was just far too slow for editing my own subtree as we had to wait on updates to be pushed back up the tree bef</p></htmltext>
<tokenext>Its going to sound like blasphemy here on slashdot , but I strongly recommend one master ActiveDirectory server with Services for Unix installed .
You can manage everything from the nice pretty windows GUI , have perfect windows support and using pam \ _krb5 and nss \ _ldap ( I use them in FreeBSD , I believe both of which were originally for linux , not sure they would be the best for it ) for pulling all your user information from AD .
Services for UNIX adds tabs to the important objects in the ActiveDirectory UI to let you edit the unix attributes.Combine nss \ _ldap , pam \ _krb5 , sasl with kerberose auth , and samba 3 or newer , the kerberos auth module for Apache and you can have complete and total authentication based on ActiveDirectory with a very nice GUI , and you can still use standard ldap tools to work with the directory if you want .
Samba will do kerberos with windows beautifully at this point , just make sure you keep eveything time synced .
Even does all the 'single signon ' stuff for websites.You end up using a great authentication mechanism on your unix AND windows hosts ( kerberos is king ) .
The only catch that may or may not apply to other OSes , but it definately bit me in FreeBSD 6 , FBSD wants to use UDP for all its kerberos communications which is normally fine , but once you get a user with a large collection of kerberos data , in my case , lots of groups either directly or via nesting , then the packets become too large for a single UDP datagram and FBSD is too stupid to switch to TCP on its on .
My solution was simply to block all UDP port 88 requests in and out of my FBSD boxes so they immediately fail over to TCP ( not , you have to return ICMP errors , not just drop packets or it 'll just hang as it does n't know the packet ca n't be sent ) .Not sure if Linux 's kerberos implementation supports forcing TCP in krb5.conf .
FreeBSD is SUPPOSED to , but older version certainly do n't.I know that no one likes MS and thinks they are evil , but I 've been VERY happy using AD .
We have two Win2k3 machines that serves ActiveDirectory , basically a primary and backup domain controller in the old MS NTDOMAIN language .
Works awesome .
If you throw in the MS certificate server on your AD server , then you also have a nice way to make internal SSL certificates with full revokation support and all that neat stuff so you can make internal certs all day long and the since your Windows machines are part of the ActiveDirectory , it pushes its root cert to all your windows boxes meaning you do n't have to do crap to make them fully authenticated certs for your windows machines.With far less effort than any other directory server you can have full single sign on support , good authentication , and an easy to use interface in which you can delegate control to various folks outside your IT department and let them use the AD manager for windows ( on xp or whatever ) to manage the department they need to if you want .
You can auth pretty much EVERY modern OS this way .
Hell if you want to you can run the servers on Unix ( OpenLDAP/MIT Kerberos ) for backup or for serving client requests and just isolate the windows machine as the master if you want.Okay , now I sound like a total fanboy , please do n't hate , but it really is a good setup .
The main reason being , from my point of view , the setup and most importantly , the administration of ActiveDirectory and Services for UNIX are FAR above and beyond anything the F/OSS world offers .
Sad , but true .
I imagine you could probably get good support from Novell eDirectory as its tools are pretty good when they work , have n't used them since 6.0 when all their Java apps were asstastic , but I was only admining the leaf node of a tree with a few hundred thousand accounts in it ( State of Georgia was using eDirectory a few years back , all their employees are in it , may have changed by now ) , so it may work better in smaller setups .
All things considered it did n't do bad there , was just far too slow for editing my own subtree as we had to wait on updates to be pushed back up the tree bef</tokentext>
<sentencetext>Its going to sound like blasphemy here on slashdot, but I strongly recommend one master ActiveDirectory server with Services for Unix installed.
You can manage everything from the nice pretty windows GUI, have perfect windows support and using pam\_krb5 and nss\_ldap (I use them in FreeBSD, I believe both of which were originally for linux, not sure they would be the best for it) for pulling all your user information from AD.
Services for UNIX adds tabs to the important objects in the ActiveDirectory UI to let you edit the unix attributes.Combine nss\_ldap, pam\_krb5, sasl with kerberose auth, and samba 3 or newer, the kerberos auth module for Apache and you can have complete and total authentication based on ActiveDirectory with a very nice GUI, and you can still use standard ldap tools to work with the directory if you want.
Samba will do kerberos with windows beautifully at this point, just make sure you keep eveything time synced.
Even does all the 'single signon' stuff for websites.You end up using a great authentication mechanism on your unix AND windows hosts (kerberos is king).
The only catch that may or may not apply to other OSes, but it definately bit me in FreeBSD 6, FBSD wants to use UDP for all its kerberos communications which is normally fine, but once you get a user with a large collection of kerberos data, in my case, lots of groups either directly or via nesting, then the packets become too large for a single UDP datagram and FBSD is too stupid to switch to TCP on its on.
My solution was simply to block all UDP port 88 requests in and out of my FBSD boxes so they immediately fail over to TCP (not, you have to return ICMP errors, not just drop packets or it'll just hang as it doesn't know the packet can't be sent).Not sure if Linux's kerberos implementation supports forcing TCP in krb5.conf.
FreeBSD is SUPPOSED to, but older version certainly don't.I know that no one likes MS and thinks they are evil, but I've been VERY happy using AD.
We have two Win2k3 machines that serves ActiveDirectory, basically a primary and backup domain controller in the old MS NTDOMAIN language.
Works awesome.
If you throw in the MS certificate server on your AD server, then you also have a nice way to make internal SSL certificates with full revokation support and all that neat stuff so you can make internal certs all day long and the  since your Windows machines are part of the ActiveDirectory, it pushes its root cert to all your windows boxes meaning you don't have to do crap to make them fully authenticated certs for your windows machines.With far less effort than any other directory server you can have full single sign on support, good authentication, and an easy to use interface in which you can delegate control to various folks outside your IT department and let them use the AD manager for windows (on xp or whatever) to manage the department they need to if you want.
You can auth pretty much EVERY modern OS this way.
Hell if you want to you can run the servers on Unix (OpenLDAP/MIT Kerberos) for backup or for serving client requests and just isolate the windows machine as the master if you want.Okay, now I sound like a total fanboy, please don't hate, but it really is a good setup.
The main reason being, from my point of view, the setup and most importantly, the administration of ActiveDirectory and Services for UNIX are FAR above and beyond anything the F/OSS world offers.
Sad, but true.
I imagine you could probably get good support from Novell eDirectory as its tools are pretty good when they work, haven't used them since 6.0 when all their Java apps were asstastic, but I was only admining the leaf node of a tree with a few hundred thousand accounts in it (State of Georgia was using eDirectory a few years back, all their employees are in it, may have changed by now), so it may work better in smaller setups.
All things considered it didn't do bad there, was just far too slow for editing my own subtree as we had to wait on updates to be pushed back up the tree bef</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214365</id>
	<title>Start with SQL</title>
	<author>unified\_diff</author>
	<datestamp>1244106780000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext><p>Yes, SQL. If you keep your raw data in SQL, it is easy to export data to any format you might need now or in the future. LDAP gets you a long way, but you will sooner or later end up with several apps that don't support it. The result is horrible password sync hacks, multiple passwords per user, etc.</p><p>The idea is to put raw user info in SQL, including their clear-text password. Of course, lock down that SQL server like you've never locked down anything before! It should have a very limited interface for updating user data. Next, export user data to relevant external databases such as LDAP, NIS, SASL, that obscure sqlite app, Kerberos, DMZ services, etc, and you'll have much less pain keeping everything in sync.</p><p>An implementation of this scheme is running on many of the biggest universities in Norway, and is called Cerebrum, <a href="http://www.cerebrum.usit.uio.no/english.html" title="usit.uio.no" rel="nofollow">http://www.cerebrum.usit.uio.no/english.html</a> [usit.uio.no]. User administration happens through a frontend interface appropriately named BOFH, where users and admins can change data in a secure manner. Users can change certain of their own attributes, while admins have more power. It's worth checking out (although their sf.net wiki seems to be down at the moment, unfortunately).</p></htmltext>
<tokenext>Yes , SQL .
If you keep your raw data in SQL , it is easy to export data to any format you might need now or in the future .
LDAP gets you a long way , but you will sooner or later end up with several apps that do n't support it .
The result is horrible password sync hacks , multiple passwords per user , etc.The idea is to put raw user info in SQL , including their clear-text password .
Of course , lock down that SQL server like you 've never locked down anything before !
It should have a very limited interface for updating user data .
Next , export user data to relevant external databases such as LDAP , NIS , SASL , that obscure sqlite app , Kerberos , DMZ services , etc , and you 'll have much less pain keeping everything in sync.An implementation of this scheme is running on many of the biggest universities in Norway , and is called Cerebrum , http : //www.cerebrum.usit.uio.no/english.html [ usit.uio.no ] .
User administration happens through a frontend interface appropriately named BOFH , where users and admins can change data in a secure manner .
Users can change certain of their own attributes , while admins have more power .
It 's worth checking out ( although their sf.net wiki seems to be down at the moment , unfortunately ) .</tokentext>
<sentencetext>Yes, SQL.
If you keep your raw data in SQL, it is easy to export data to any format you might need now or in the future.
LDAP gets you a long way, but you will sooner or later end up with several apps that don't support it.
The result is horrible password sync hacks, multiple passwords per user, etc.The idea is to put raw user info in SQL, including their clear-text password.
Of course, lock down that SQL server like you've never locked down anything before!
It should have a very limited interface for updating user data.
Next, export user data to relevant external databases such as LDAP, NIS, SASL, that obscure sqlite app, Kerberos, DMZ services, etc, and you'll have much less pain keeping everything in sync.An implementation of this scheme is running on many of the biggest universities in Norway, and is called Cerebrum, http://www.cerebrum.usit.uio.no/english.html [usit.uio.no].
User administration happens through a frontend interface appropriately named BOFH, where users and admins can change data in a secure manner.
Users can change certain of their own attributes, while admins have more power.
It's worth checking out (although their sf.net wiki seems to be down at the moment, unfortunately).</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214753</id>
	<title>Use AD</title>
	<author>Anonymous</author>
	<datestamp>1244108880000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>There are times to show off to the world how much of a geek you really are, but this is not one of them - why reinvent the wheel? Just use AD. It works.</htmltext>
<tokenext>There are times to show off to the world how much of a geek you really are , but this is not one of them - why reinvent the wheel ?
Just use AD .
It works .</tokentext>
<sentencetext>There are times to show off to the world how much of a geek you really are, but this is not one of them - why reinvent the wheel?
Just use AD.
It works.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214341</id>
	<title>Re:My choices</title>
	<author>d235j</author>
	<datestamp>1244106660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Yes, I agree that RHDS/FDS aka. 389 directory server (directory.fedoraproject.org) is probably the way to go.</htmltext>
<tokenext>Yes , I agree that RHDS/FDS aka .
389 directory server ( directory.fedoraproject.org ) is probably the way to go .</tokentext>
<sentencetext>Yes, I agree that RHDS/FDS aka.
389 directory server (directory.fedoraproject.org) is probably the way to go.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213913</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213951</id>
	<title>Re:Easy</title>
	<author>The Yuckinator</author>
	<datestamp>1244148180000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>If you do decide to go with an Active Directory, I found that using <a href="http://www.enterprisenetworkingplanet.com/netos/article.php/3502441" title="enterprise...planet.com" rel="nofollow">Winbind </a> [enterprise...planet.com] was an extremely easy way to have my Samba server authenticate my users from the AD.  It was up and running in no time and it's been rock solid ever since.  <br> <br>
One thing to remember is to use <a href="http://www.udel.edu/topics/os/unix/general/groupsharing.html" title="udel.edu" rel="nofollow">Group Sharing</a> [udel.edu] when setting folder permissions on the *nix box.   That was an easy one to overlook until users started asking why they couldn't open each others files!</htmltext>
<tokenext>If you do decide to go with an Active Directory , I found that using Winbind [ enterprise...planet.com ] was an extremely easy way to have my Samba server authenticate my users from the AD .
It was up and running in no time and it 's been rock solid ever since .
One thing to remember is to use Group Sharing [ udel.edu ] when setting folder permissions on the * nix box .
That was an easy one to overlook until users started asking why they could n't open each others files !</tokentext>
<sentencetext>If you do decide to go with an Active Directory, I found that using Winbind  [enterprise...planet.com] was an extremely easy way to have my Samba server authenticate my users from the AD.
It was up and running in no time and it's been rock solid ever since.
One thing to remember is to use Group Sharing [udel.edu] when setting folder permissions on the *nix box.
That was an easy one to overlook until users started asking why they couldn't open each others files!</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213723</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28219337</id>
	<title>Re:My choices</title>
	<author>Anonymous</author>
	<datestamp>1244234460000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>1</modscore>
	<htmltext><p>use freeipa! it's the community version of redhat enterprise ipa (identity, policy, audit) and it offers a very complete<br>solution for your needs. and it's open... from the site:</p><p>FreeIPA (so far) is an integrated solution combining</p><p>
&nbsp; &nbsp; &nbsp; &nbsp; * Linux (currently Fedora)<br>
&nbsp; &nbsp; &nbsp; &nbsp; * Fedora Directory Server<br>
&nbsp; &nbsp; &nbsp; &nbsp; * MIT Kerberos<br>
&nbsp; &nbsp; &nbsp; &nbsp; * NTP<br>
&nbsp; &nbsp; &nbsp; &nbsp; * DNS<br>
&nbsp; &nbsp; &nbsp; &nbsp; * Web and commandline provisioning and administration tools</p></htmltext>
<tokenext>use freeipa !
it 's the community version of redhat enterprise ipa ( identity , policy , audit ) and it offers a very completesolution for your needs .
and it 's open... from the site : FreeIPA ( so far ) is an integrated solution combining         * Linux ( currently Fedora )         * Fedora Directory Server         * MIT Kerberos         * NTP         * DNS         * Web and commandline provisioning and administration tools</tokentext>
<sentencetext>use freeipa!
it's the community version of redhat enterprise ipa (identity, policy, audit) and it offers a very completesolution for your needs.
and it's open... from the site:FreeIPA (so far) is an integrated solution combining
        * Linux (currently Fedora)
        * Fedora Directory Server
        * MIT Kerberos
        * NTP
        * DNS
        * Web and commandline provisioning and administration tools</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213913</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214571</id>
	<title>emoticons</title>
	<author>AltImage</author>
	<datestamp>1244108040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Is it really necessary to have 6 smilie faces in the article? I wonder how many also show up in the Drizzle source. I also find it interesting that the author opts for the less common "no-nose smilie face"<nobr> <wbr></nobr>:)</htmltext>
<tokenext>Is it really necessary to have 6 smilie faces in the article ?
I wonder how many also show up in the Drizzle source .
I also find it interesting that the author opts for the less common " no-nose smilie face " : )</tokentext>
<sentencetext>Is it really necessary to have 6 smilie faces in the article?
I wonder how many also show up in the Drizzle source.
I also find it interesting that the author opts for the less common "no-nose smilie face" :)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28215951</id>
	<title>Single sign on software</title>
	<author>Anonymous</author>
	<datestamp>1244115060000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Or there's something like <a href="http://symplified.com/" title="symplified.com" rel="nofollow">symplified</a> [symplified.com], they have a single sign on software that's made specifically for this sort of purpose. It's not F/OSS though, so keep that in mind too, but I looked into it recently and it seemed pretty nice.</p></htmltext>
<tokenext>Or there 's something like symplified [ symplified.com ] , they have a single sign on software that 's made specifically for this sort of purpose .
It 's not F/OSS though , so keep that in mind too , but I looked into it recently and it seemed pretty nice .</tokentext>
<sentencetext>Or there's something like symplified [symplified.com], they have a single sign on software that's made specifically for this sort of purpose.
It's not F/OSS though, so keep that in mind too, but I looked into it recently and it seemed pretty nice.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28217187</id>
	<title>openldap</title>
	<author>Anonymous</author>
	<datestamp>1244122860000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>seriously... this is a freakin' M$ love-in...<br>since when has "simple", "gui" and "proprietory" been pre-requisits on slashdot?<br>AD is far from the best tool for the job for hetrogenous computing environments. it has limitations in the number of entities it can hold, it's buggier than a swamp and the granularity of security imnsfho, crap. if you decide to get on the AD train, don't forget to purchase ADAM as the recomended and part-of-the-solution-set to get anything to play nice that isn't winblows.<br>if, like me, you like to put in place solid, stable, secure and infinitely configurable systems and infrastructure, but *nix is all scary, try putting "howto" in front of you google search, here's what I found, and it works. just works. keeps working.</p><p>http://www.kernel-panic.it/openbsd/pdc/</p><p>if you're setting this up for a dev shop, the code monkey's will love you when finally a suit comes around dropping jargon like "single sign-on" - they can code against technology that doesn't cost an arm and a leg, is completely documented and adheres to "standards" - those are the things M$ never attain.</p><p>anyhoo, enjoy the infrastructure building, just remember - if a tarded microserf can't do it with one click, then the tarded microserf can't f##k it up.</p></htmltext>
<tokenext>seriously... this is a freakin ' M $ love-in...since when has " simple " , " gui " and " proprietory " been pre-requisits on slashdot ? AD is far from the best tool for the job for hetrogenous computing environments .
it has limitations in the number of entities it can hold , it 's buggier than a swamp and the granularity of security imnsfho , crap .
if you decide to get on the AD train , do n't forget to purchase ADAM as the recomended and part-of-the-solution-set to get anything to play nice that is n't winblows.if , like me , you like to put in place solid , stable , secure and infinitely configurable systems and infrastructure , but * nix is all scary , try putting " howto " in front of you google search , here 's what I found , and it works .
just works .
keeps working.http : //www.kernel-panic.it/openbsd/pdc/if you 're setting this up for a dev shop , the code monkey 's will love you when finally a suit comes around dropping jargon like " single sign-on " - they can code against technology that does n't cost an arm and a leg , is completely documented and adheres to " standards " - those are the things M $ never attain.anyhoo , enjoy the infrastructure building , just remember - if a tarded microserf ca n't do it with one click , then the tarded microserf ca n't f # # k it up .</tokentext>
<sentencetext>seriously... this is a freakin' M$ love-in...since when has "simple", "gui" and "proprietory" been pre-requisits on slashdot?AD is far from the best tool for the job for hetrogenous computing environments.
it has limitations in the number of entities it can hold, it's buggier than a swamp and the granularity of security imnsfho, crap.
if you decide to get on the AD train, don't forget to purchase ADAM as the recomended and part-of-the-solution-set to get anything to play nice that isn't winblows.if, like me, you like to put in place solid, stable, secure and infinitely configurable systems and infrastructure, but *nix is all scary, try putting "howto" in front of you google search, here's what I found, and it works.
just works.
keeps working.http://www.kernel-panic.it/openbsd/pdc/if you're setting this up for a dev shop, the code monkey's will love you when finally a suit comes around dropping jargon like "single sign-on" - they can code against technology that doesn't cost an arm and a leg, is completely documented and adheres to "standards" - those are the things M$ never attain.anyhoo, enjoy the infrastructure building, just remember - if a tarded microserf can't do it with one click, then the tarded microserf can't f##k it up.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28224755</id>
	<title>Re:Hear me out</title>
	<author>illumin8</author>
	<datestamp>1244225520000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>I know that no one likes MS and thinks they are evil, but I've been VERY happy using AD. We have two Win2k3 machines that serves ActiveDirectory, basically a primary and backup domain controller in the old MS NTDOMAIN language. Works awesome. If you throw in the MS certificate server on your AD server, then you also have a nice way to make internal SSL certificates with full revokation support and all that neat stuff so you can make internal certs all day long and the since your Windows machines are part of the ActiveDirectory, it pushes its root cert to all your windows boxes meaning you don't have to do crap to make them fully authenticated certs for your windows machines.</p></div></blockquote><p>I totally agree that this is the best solution out there.  MS AD, Certificate server pushing root CA out to the Windows clients, using IE and getting a trusted root from your certificate server.  But it strikes me as another sysadmin reading through your post, how completely Microsoft has locked down all the key infrastructure:</p><p>1. Directory Services - Check, AD is the best product on the market and the only one that integrates well with Windows clients out of the box.<br>2. Authentication - Check, AD is the only one that can provide seamless authentication to Windows clients, Kerberos to *nix, and LDAP to web apps.<br>3. Certificate Authority - Check, MS Cert server is the only one capable of pushing trusted root certs out to Windows client browsers through group policies.</p><p>While this is by far, the best all in one solution out there, it pains me to think that after all the evil business practices and anti competitive tactics Microsoft has used over the years, they have been able to completely lock down the enterprise in such a huge way.  Nothing, literally no network service, even if it's a login to a *nix database server or a CRM application on the web, can function without them.  Please excuse me while I go cry a little...</p></div>
	</htmltext>
<tokenext>I know that no one likes MS and thinks they are evil , but I 've been VERY happy using AD .
We have two Win2k3 machines that serves ActiveDirectory , basically a primary and backup domain controller in the old MS NTDOMAIN language .
Works awesome .
If you throw in the MS certificate server on your AD server , then you also have a nice way to make internal SSL certificates with full revokation support and all that neat stuff so you can make internal certs all day long and the since your Windows machines are part of the ActiveDirectory , it pushes its root cert to all your windows boxes meaning you do n't have to do crap to make them fully authenticated certs for your windows machines.I totally agree that this is the best solution out there .
MS AD , Certificate server pushing root CA out to the Windows clients , using IE and getting a trusted root from your certificate server .
But it strikes me as another sysadmin reading through your post , how completely Microsoft has locked down all the key infrastructure : 1 .
Directory Services - Check , AD is the best product on the market and the only one that integrates well with Windows clients out of the box.2 .
Authentication - Check , AD is the only one that can provide seamless authentication to Windows clients , Kerberos to * nix , and LDAP to web apps.3 .
Certificate Authority - Check , MS Cert server is the only one capable of pushing trusted root certs out to Windows client browsers through group policies.While this is by far , the best all in one solution out there , it pains me to think that after all the evil business practices and anti competitive tactics Microsoft has used over the years , they have been able to completely lock down the enterprise in such a huge way .
Nothing , literally no network service , even if it 's a login to a * nix database server or a CRM application on the web , can function without them .
Please excuse me while I go cry a little.. .</tokentext>
<sentencetext>I know that no one likes MS and thinks they are evil, but I've been VERY happy using AD.
We have two Win2k3 machines that serves ActiveDirectory, basically a primary and backup domain controller in the old MS NTDOMAIN language.
Works awesome.
If you throw in the MS certificate server on your AD server, then you also have a nice way to make internal SSL certificates with full revokation support and all that neat stuff so you can make internal certs all day long and the since your Windows machines are part of the ActiveDirectory, it pushes its root cert to all your windows boxes meaning you don't have to do crap to make them fully authenticated certs for your windows machines.I totally agree that this is the best solution out there.
MS AD, Certificate server pushing root CA out to the Windows clients, using IE and getting a trusted root from your certificate server.
But it strikes me as another sysadmin reading through your post, how completely Microsoft has locked down all the key infrastructure:1.
Directory Services - Check, AD is the best product on the market and the only one that integrates well with Windows clients out of the box.2.
Authentication - Check, AD is the only one that can provide seamless authentication to Windows clients, Kerberos to *nix, and LDAP to web apps.3.
Certificate Authority - Check, MS Cert server is the only one capable of pushing trusted root certs out to Windows client browsers through group policies.While this is by far, the best all in one solution out there, it pains me to think that after all the evil business practices and anti competitive tactics Microsoft has used over the years, they have been able to completely lock down the enterprise in such a huge way.
Nothing, literally no network service, even if it's a login to a *nix database server or a CRM application on the web, can function without them.
Please excuse me while I go cry a little...
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214727</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214305</id>
	<title>AD is what MS got very very very close to "Right"</title>
	<author>IMightB</author>
	<datestamp>1244106480000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Ad is very nice, we use it for Auth in a mixed env as well.   I work in QA, the way that I've actually got mine setup is ADS run by Corp, FDS run by QA.  FDS has Pass Though Authentication turned on.</p><p>You may want to checkout Fedora Directory Server and FreeIPA combo for linux/unix solutions</p></htmltext>
<tokenext>Ad is very nice , we use it for Auth in a mixed env as well .
I work in QA , the way that I 've actually got mine setup is ADS run by Corp , FDS run by QA .
FDS has Pass Though Authentication turned on.You may want to checkout Fedora Directory Server and FreeIPA combo for linux/unix solutions</tokentext>
<sentencetext>Ad is very nice, we use it for Auth in a mixed env as well.
I work in QA, the way that I've actually got mine setup is ADS run by Corp, FDS run by QA.
FDS has Pass Though Authentication turned on.You may want to checkout Fedora Directory Server and FreeIPA combo for linux/unix solutions</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28217811</id>
	<title>OpenLDAP is the way</title>
	<author>Anonymous</author>
	<datestamp>1244129700000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>
&nbsp; I replaced an AD domain with Samba/OpenLDAP, in a mid-sized enterprise of 13 networks nationwide (~30 windows boxes each), it works like clockwork. AD works allright, but until there's a Linux version of it, you'll be enslaved to the whole Microsoft administration nightmare experience: restart-every-x-weeks/update-patch/virus-proneness etc. including the MS tax of course, wich includes call-licenses (one per client)...</p><p>OpenLDAP Pros:<br>Robustness: it's a snap to set up replicas everywhere.<br>Efficient: faster in the same hardware than a win2003/AD, the bandwidth and time needed for replication is nothing compared to what AD needs, also you don't need a cluster to make it robust, it just is.<br>Simple to set up if you are using the packaged version (I've used Ubuntu's and Debian's versions, they work out of the box), although for specific customization/needs it may not be as simple as clicking NEXT until your index finger is sore.<br>Flexible: you can authenticate almost anything against it, there are decent LDAP libraries for most programming languages, and you can pick your choice middleman authenticator: Samba, PAM, Radius, or even POP3, to name a few.<br>Secure: if you have your own x509 PKI (and you should), it's easy to have everything working under SSL.<br>Good documentation and support: there's already a ton of how-tos and tutorials on how to get it working and there's always the mailing lists and forums.<br>Easy to troubleshoot: just increase the verbosity of log/debug levels and you can figure out exactly what you've missed.<br>Easy to back up and recover: back up your database to a plaintext ldif file and recover/create new replicas in a blink.<br>Oh, and it's Free software.</p><p>Cons:<br>It's not AD, so AD magical stuff for winXP/Vista is not there yet, but wait for the next version of samba and you'll get some of it if you really need it.<br>You need to read a little and actually understand what you are doing to set it up, but the time you spend learning how to setup OpenLDAP is but a fraction of the time you'll spend actually managing an AD network.</p><p>OpenLDAP has really simplified things around, users have a single account for: windows domain, squid proxy, apache, jabber, email, webapps etc. And it also holds postfix's virtual aliases and squid's ACLs. Everything in a single replicated, secure 'place'.</p></htmltext>
<tokenext>  I replaced an AD domain with Samba/OpenLDAP , in a mid-sized enterprise of 13 networks nationwide ( ~ 30 windows boxes each ) , it works like clockwork .
AD works allright , but until there 's a Linux version of it , you 'll be enslaved to the whole Microsoft administration nightmare experience : restart-every-x-weeks/update-patch/virus-proneness etc .
including the MS tax of course , wich includes call-licenses ( one per client ) ...OpenLDAP Pros : Robustness : it 's a snap to set up replicas everywhere.Efficient : faster in the same hardware than a win2003/AD , the bandwidth and time needed for replication is nothing compared to what AD needs , also you do n't need a cluster to make it robust , it just is.Simple to set up if you are using the packaged version ( I 've used Ubuntu 's and Debian 's versions , they work out of the box ) , although for specific customization/needs it may not be as simple as clicking NEXT until your index finger is sore.Flexible : you can authenticate almost anything against it , there are decent LDAP libraries for most programming languages , and you can pick your choice middleman authenticator : Samba , PAM , Radius , or even POP3 , to name a few.Secure : if you have your own x509 PKI ( and you should ) , it 's easy to have everything working under SSL.Good documentation and support : there 's already a ton of how-tos and tutorials on how to get it working and there 's always the mailing lists and forums.Easy to troubleshoot : just increase the verbosity of log/debug levels and you can figure out exactly what you 've missed.Easy to back up and recover : back up your database to a plaintext ldif file and recover/create new replicas in a blink.Oh , and it 's Free software.Cons : It 's not AD , so AD magical stuff for winXP/Vista is not there yet , but wait for the next version of samba and you 'll get some of it if you really need it.You need to read a little and actually understand what you are doing to set it up , but the time you spend learning how to setup OpenLDAP is but a fraction of the time you 'll spend actually managing an AD network.OpenLDAP has really simplified things around , users have a single account for : windows domain , squid proxy , apache , jabber , email , webapps etc .
And it also holds postfix 's virtual aliases and squid 's ACLs .
Everything in a single replicated , secure 'place' .</tokentext>
<sentencetext>
  I replaced an AD domain with Samba/OpenLDAP, in a mid-sized enterprise of 13 networks nationwide (~30 windows boxes each), it works like clockwork.
AD works allright, but until there's a Linux version of it, you'll be enslaved to the whole Microsoft administration nightmare experience: restart-every-x-weeks/update-patch/virus-proneness etc.
including the MS tax of course, wich includes call-licenses (one per client)...OpenLDAP Pros:Robustness: it's a snap to set up replicas everywhere.Efficient: faster in the same hardware than a win2003/AD, the bandwidth and time needed for replication is nothing compared to what AD needs, also you don't need a cluster to make it robust, it just is.Simple to set up if you are using the packaged version (I've used Ubuntu's and Debian's versions, they work out of the box), although for specific customization/needs it may not be as simple as clicking NEXT until your index finger is sore.Flexible: you can authenticate almost anything against it, there are decent LDAP libraries for most programming languages, and you can pick your choice middleman authenticator: Samba, PAM, Radius, or even POP3, to name a few.Secure: if you have your own x509 PKI (and you should), it's easy to have everything working under SSL.Good documentation and support: there's already a ton of how-tos and tutorials on how to get it working and there's always the mailing lists and forums.Easy to troubleshoot: just increase the verbosity of log/debug levels and you can figure out exactly what you've missed.Easy to back up and recover: back up your database to a plaintext ldif file and recover/create new replicas in a blink.Oh, and it's Free software.Cons:It's not AD, so AD magical stuff for winXP/Vista is not there yet, but wait for the next version of samba and you'll get some of it if you really need it.You need to read a little and actually understand what you are doing to set it up, but the time you spend learning how to setup OpenLDAP is but a fraction of the time you'll spend actually managing an AD network.OpenLDAP has really simplified things around, users have a single account for: windows domain, squid proxy, apache, jabber, email, webapps etc.
And it also holds postfix's virtual aliases and squid's ACLs.
Everything in a single replicated, secure 'place'.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28231271</id>
	<title>Licensing for Windows AD server</title>
	<author>Kirth Gersen</author>
	<datestamp>1244283780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The OP mentioned that "we are primarily a Linux shop, there are a handful of Windows systems that will be on a Windows Active Directory domain".</p><p>Does every machine that authenticates to an AD server need a Windows client licence? Or every user? Does the AD server need an additional client or user licence?</p><p>I haven't bought client licences for years -- it was back in NT4 days -- but as I recall they were pricey and hard to get. And nobody was prepared to go on the record about how to calculate how many I needed. (Although several people said things that were vague and inconsistent and then stopped returning calls.) Maybe that has changed.</p></htmltext>
<tokenext>The OP mentioned that " we are primarily a Linux shop , there are a handful of Windows systems that will be on a Windows Active Directory domain " .Does every machine that authenticates to an AD server need a Windows client licence ?
Or every user ?
Does the AD server need an additional client or user licence ? I have n't bought client licences for years -- it was back in NT4 days -- but as I recall they were pricey and hard to get .
And nobody was prepared to go on the record about how to calculate how many I needed .
( Although several people said things that were vague and inconsistent and then stopped returning calls .
) Maybe that has changed .</tokentext>
<sentencetext>The OP mentioned that "we are primarily a Linux shop, there are a handful of Windows systems that will be on a Windows Active Directory domain".Does every machine that authenticates to an AD server need a Windows client licence?
Or every user?
Does the AD server need an additional client or user licence?I haven't bought client licences for years -- it was back in NT4 days -- but as I recall they were pricey and hard to get.
And nobody was prepared to go on the record about how to calculate how many I needed.
(Although several people said things that were vague and inconsistent and then stopped returning calls.
) Maybe that has changed.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214461</id>
	<title>Choose AD</title>
	<author>wasabii</author>
	<datestamp>1244107320000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>I'd use AD for everything. It works out of the box. Isn't that expensive. Does replication properly. Tracks site locality. Is expandable instantly to huge networks. Has Kerberos set up perfectly by default. There's really no downside to using it in my experience. All of hte other solutions require massive hand holding. Linux can auth against it either as a normal LDAP directory, or using Winbind. Winbind recommended.</htmltext>
<tokenext>I 'd use AD for everything .
It works out of the box .
Is n't that expensive .
Does replication properly .
Tracks site locality .
Is expandable instantly to huge networks .
Has Kerberos set up perfectly by default .
There 's really no downside to using it in my experience .
All of hte other solutions require massive hand holding .
Linux can auth against it either as a normal LDAP directory , or using Winbind .
Winbind recommended .</tokentext>
<sentencetext>I'd use AD for everything.
It works out of the box.
Isn't that expensive.
Does replication properly.
Tracks site locality.
Is expandable instantly to huge networks.
Has Kerberos set up perfectly by default.
There's really no downside to using it in my experience.
All of hte other solutions require massive hand holding.
Linux can auth against it either as a normal LDAP directory, or using Winbind.
Winbind recommended.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28220569</id>
	<title>What about SUN OpenSSO/OpenDS ?</title>
	<author>binarymaster</author>
	<datestamp>1244206860000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I am implementing OpenSSO in my office, and we use the SUN Directory Server (instead of OpenDS). They seem to work very well. Integration with AD (if you really need it) is easy to do. Both OpenSSO and OpenDS are available at no cost. You only pay for the support, and the publicly available knowledge base is usually good enough.</htmltext>
<tokenext>I am implementing OpenSSO in my office , and we use the SUN Directory Server ( instead of OpenDS ) .
They seem to work very well .
Integration with AD ( if you really need it ) is easy to do .
Both OpenSSO and OpenDS are available at no cost .
You only pay for the support , and the publicly available knowledge base is usually good enough .</tokentext>
<sentencetext>I am implementing OpenSSO in my office, and we use the SUN Directory Server (instead of OpenDS).
They seem to work very well.
Integration with AD (if you really need it) is easy to do.
Both OpenSSO and OpenDS are available at no cost.
You only pay for the support, and the publicly available knowledge base is usually good enough.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213925</id>
	<title>A side benefit of Active Directory:</title>
	<author>lazyforker</author>
	<datestamp>1244148000000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext>Almost any LDAP Directory service will work for your directory needs.  I think the real question should be "is the cost of the Windows Server 2008+CALs outweighed by the extra features I get?".  If you're considering Active Directory then you should know that as a bare minimum you will need two Windows Servers.  But you will get GPOs, centralized security (domain users and groups) etc.  Do you need all that?  If you're a startup then spend money on getting your business up and running, not on keeping Ballmer's office stocked with chairs.  So stick with any of the worthy Linux-based. FOSS solutions - I have limited experience with them so I'll leave others to comment on which is "best".  (Disclaimer: I deployed AD to my company - they're a 10,000 employee global company that was running Windows NT everywhere when I joined.)</htmltext>
<tokenext>Almost any LDAP Directory service will work for your directory needs .
I think the real question should be " is the cost of the Windows Server 2008 + CALs outweighed by the extra features I get ? " .
If you 're considering Active Directory then you should know that as a bare minimum you will need two Windows Servers .
But you will get GPOs , centralized security ( domain users and groups ) etc .
Do you need all that ?
If you 're a startup then spend money on getting your business up and running , not on keeping Ballmer 's office stocked with chairs .
So stick with any of the worthy Linux-based .
FOSS solutions - I have limited experience with them so I 'll leave others to comment on which is " best " .
( Disclaimer : I deployed AD to my company - they 're a 10,000 employee global company that was running Windows NT everywhere when I joined .
)</tokentext>
<sentencetext>Almost any LDAP Directory service will work for your directory needs.
I think the real question should be "is the cost of the Windows Server 2008+CALs outweighed by the extra features I get?".
If you're considering Active Directory then you should know that as a bare minimum you will need two Windows Servers.
But you will get GPOs, centralized security (domain users and groups) etc.
Do you need all that?
If you're a startup then spend money on getting your business up and running, not on keeping Ballmer's office stocked with chairs.
So stick with any of the worthy Linux-based.
FOSS solutions - I have limited experience with them so I'll leave others to comment on which is "best".
(Disclaimer: I deployed AD to my company - they're a 10,000 employee global company that was running Windows NT everywhere when I joined.
)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28219639</id>
	<title>AD if you ever think about connecting 3rd parties</title>
	<author>trastomatic</author>
	<datestamp>1244195460000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Aside from your current mix of boxes, you have to consider other things from other vendors in the future (present?). <br> <br>Think of: <br>
1) IP-PBX connected to your directory to auth users<br>
2) firewall, to define rules based on users, not IPs. (same for other firewall-like features such as VPN)<br>
3) management platforms, CRMs, ERPs, where you'll need RBAC<br>
<br>
And many others.<br>
<br>
While some of them can connect/use/sync to any LDAP-compatible directory, some (most) others are just certified to work with Microsoft AD.
<br>
If you feel there's a lack of openness, set up a secondary RH, Fedora, OpenLDAP, whatever and sync with the AD. Or do the other way round, AD sync'ing to the open LDAP, but I would recommend having a usable Microsoft AD somewhere in your network.</htmltext>
<tokenext>Aside from your current mix of boxes , you have to consider other things from other vendors in the future ( present ? ) .
Think of : 1 ) IP-PBX connected to your directory to auth users 2 ) firewall , to define rules based on users , not IPs .
( same for other firewall-like features such as VPN ) 3 ) management platforms , CRMs , ERPs , where you 'll need RBAC And many others .
While some of them can connect/use/sync to any LDAP-compatible directory , some ( most ) others are just certified to work with Microsoft AD .
If you feel there 's a lack of openness , set up a secondary RH , Fedora , OpenLDAP , whatever and sync with the AD .
Or do the other way round , AD sync'ing to the open LDAP , but I would recommend having a usable Microsoft AD somewhere in your network .</tokentext>
<sentencetext>Aside from your current mix of boxes, you have to consider other things from other vendors in the future (present?).
Think of: 
1) IP-PBX connected to your directory to auth users
2) firewall, to define rules based on users, not IPs.
(same for other firewall-like features such as VPN)
3) management platforms, CRMs, ERPs, where you'll need RBAC

And many others.
While some of them can connect/use/sync to any LDAP-compatible directory, some (most) others are just certified to work with Microsoft AD.
If you feel there's a lack of openness, set up a secondary RH, Fedora, OpenLDAP, whatever and sync with the AD.
Or do the other way round, AD sync'ing to the open LDAP, but I would recommend having a usable Microsoft AD somewhere in your network.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28221205</id>
	<title>Ah I recall the movie "Office Space" for this one</title>
	<author>keneng</author>
	<datestamp>1244211180000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Take your machines that are running AD, and then follow the example of the Office Space staff when they brought the Fax Machine/Printer to the park.  Don't forget the rap music too.</p><p>After that, use the already existing open-source solutions on a Linux box.</p><p>It's the right thing to do.</p></htmltext>
<tokenext>Take your machines that are running AD , and then follow the example of the Office Space staff when they brought the Fax Machine/Printer to the park .
Do n't forget the rap music too.After that , use the already existing open-source solutions on a Linux box.It 's the right thing to do .</tokentext>
<sentencetext>Take your machines that are running AD, and then follow the example of the Office Space staff when they brought the Fax Machine/Printer to the park.
Don't forget the rap music too.After that, use the already existing open-source solutions on a Linux box.It's the right thing to do.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28217161</id>
	<title>Re:FreeIPA, Apple OD, Gosa2, Novell eDirectory, FD</title>
	<author>adriccom</author>
	<datestamp>1244122620000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>Yikes, I'm replying to an AC.</p><p>Mac OS X and Server are now virtualizable in recent Vmware Fusion and Parallels installs (at least). Although there were technical and legal challenges to parallelizing OS X installs, these have apparently been surmounted.</p><p>Now I just need more RAM.</p></htmltext>
<tokenext>Yikes , I 'm replying to an AC.Mac OS X and Server are now virtualizable in recent Vmware Fusion and Parallels installs ( at least ) .
Although there were technical and legal challenges to parallelizing OS X installs , these have apparently been surmounted.Now I just need more RAM .</tokentext>
<sentencetext>Yikes, I'm replying to an AC.Mac OS X and Server are now virtualizable in recent Vmware Fusion and Parallels installs (at least).
Although there were technical and legal challenges to parallelizing OS X installs, these have apparently been surmounted.Now I just need more RAM.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214801</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214335</id>
	<title>Re:My choices</title>
	<author>IMightB</author>
	<datestamp>1244106660000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>1</modscore>
	<htmltext><p>SunDS, FDS and Novell eDirectory are all based on Netscapes DS,</p><p>FDS and RHDS are the direct descendants of Netscape DS, which was purchased by AOL and then by Redhat who then Open Sourced it.</p></htmltext>
<tokenext>SunDS , FDS and Novell eDirectory are all based on Netscapes DS,FDS and RHDS are the direct descendants of Netscape DS , which was purchased by AOL and then by Redhat who then Open Sourced it .</tokentext>
<sentencetext>SunDS, FDS and Novell eDirectory are all based on Netscapes DS,FDS and RHDS are the direct descendants of Netscape DS, which was purchased by AOL and then by Redhat who then Open Sourced it.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213913</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214161</id>
	<title>Support</title>
	<author>Cyner</author>
	<datestamp>1244148960000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>You can configure a Samba server against LDAP and have everything authenticate agaist that. Your biggest pitfall is going to be finding support for the configuration. You have to consider "what if the IT Admin get's hit by a bus, who's going to support this configuration". With Active Directory you can flip open a phonebook and find a dozen local places that will support it; that's not the case with the Samba/LDAP configuration.</p></htmltext>
<tokenext>You can configure a Samba server against LDAP and have everything authenticate agaist that .
Your biggest pitfall is going to be finding support for the configuration .
You have to consider " what if the IT Admin get 's hit by a bus , who 's going to support this configuration " .
With Active Directory you can flip open a phonebook and find a dozen local places that will support it ; that 's not the case with the Samba/LDAP configuration .</tokentext>
<sentencetext>You can configure a Samba server against LDAP and have everything authenticate agaist that.
Your biggest pitfall is going to be finding support for the configuration.
You have to consider "what if the IT Admin get's hit by a bus, who's going to support this configuration".
With Active Directory you can flip open a phonebook and find a dozen local places that will support it; that's not the case with the Samba/LDAP configuration.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28217459</id>
	<title>Re:AD</title>
	<author>JSG</author>
	<datestamp>1244125320000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Please describe your experiences with any other directory to reinforce your expertise.</p></htmltext>
<tokenext>Please describe your experiences with any other directory to reinforce your expertise .</tokentext>
<sentencetext>Please describe your experiences with any other directory to reinforce your expertise.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214011</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28217823</id>
	<title>Re:Just go with AD</title>
	<author>CAIMLAS</author>
	<datestamp>1244129760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>It's been a while since I've looked at Windows licensing, and they do tend to change things from version to version, but I seem to recall that MS offers two client/connection licensing models (which are mixable): per-server or per-client. At the least, Windows Server only tracks licenses by concurrent connections to the server in per-user licensing. They might also offer a per-domain model.</p><p>It's all pretty convoluted, I'll give you that.</p></htmltext>
<tokenext>It 's been a while since I 've looked at Windows licensing , and they do tend to change things from version to version , but I seem to recall that MS offers two client/connection licensing models ( which are mixable ) : per-server or per-client .
At the least , Windows Server only tracks licenses by concurrent connections to the server in per-user licensing .
They might also offer a per-domain model.It 's all pretty convoluted , I 'll give you that .</tokentext>
<sentencetext>It's been a while since I've looked at Windows licensing, and they do tend to change things from version to version, but I seem to recall that MS offers two client/connection licensing models (which are mixable): per-server or per-client.
At the least, Windows Server only tracks licenses by concurrent connections to the server in per-user licensing.
They might also offer a per-domain model.It's all pretty convoluted, I'll give you that.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214393</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214263</id>
	<title>Try FreeIPA</title>
	<author>fwittekind</author>
	<datestamp>1244106240000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>http://www.freeipa.org/</p></htmltext>
<tokenext>http : //www.freeipa.org/</tokentext>
<sentencetext>http://www.freeipa.org/</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214827</id>
	<title>The /. M$ effect</title>
	<author>Anonymous</author>
	<datestamp>1244109180000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Everyone hating on MS but loving AD. Sweet sweet irony.</p></htmltext>
<tokenext>Everyone hating on MS but loving AD .
Sweet sweet irony .</tokentext>
<sentencetext>Everyone hating on MS but loving AD.
Sweet sweet irony.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214627</id>
	<title>Novel Zen</title>
	<author>Anonymous</author>
	<datestamp>1244108400000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Novel sells Zen, which does an LDAP domain like AD, hosted from Linux.  Yes there might be incompatibilities with Windows, but Windows typically has incompatibilities with Windows too.  Novel's stuff will probably support your UNIX systems better.  The admins I've met running Novel seemed happy with it, especially with the security features and invulnerability (low incidence)  to typical internet malware.</p><p>Also, you are missing the point of LDAP and AD.  LDAP directory services can TALK TO EACH OTHER.  It's based on standards.  You can have a Linux-based LDAP forest talk to a Windows-based AD forest.  It will work.  There may/will be problems, but consider this:</p><p>most of the time, your linux servers will deal with the linux LDAP server<br>most of the time, your windows servers will deal with the windows domain</p><p>file &amp; data transfers can also be done a variety of ways that don't involve directory services.  SSH with private key auth.  The HTTP your using now is another.</p><p>If system administration is becoming a burden, you just need to automate more.  Write more scripts.  Work as a team to automate most tasks until you have less and less to do.  A perfect, orderly domain doesn't exist and may cause more problems than it solves.  Cron/scheduler that downloads new/updated scripts from a central server can solve a lot of these issues without all the overhead and licensing, especially if you have special vendor application that can't run in a domain (the vendor won't support it).</p></htmltext>
<tokenext>Novel sells Zen , which does an LDAP domain like AD , hosted from Linux .
Yes there might be incompatibilities with Windows , but Windows typically has incompatibilities with Windows too .
Novel 's stuff will probably support your UNIX systems better .
The admins I 've met running Novel seemed happy with it , especially with the security features and invulnerability ( low incidence ) to typical internet malware.Also , you are missing the point of LDAP and AD .
LDAP directory services can TALK TO EACH OTHER .
It 's based on standards .
You can have a Linux-based LDAP forest talk to a Windows-based AD forest .
It will work .
There may/will be problems , but consider this : most of the time , your linux servers will deal with the linux LDAP servermost of the time , your windows servers will deal with the windows domainfile &amp; data transfers can also be done a variety of ways that do n't involve directory services .
SSH with private key auth .
The HTTP your using now is another.If system administration is becoming a burden , you just need to automate more .
Write more scripts .
Work as a team to automate most tasks until you have less and less to do .
A perfect , orderly domain does n't exist and may cause more problems than it solves .
Cron/scheduler that downloads new/updated scripts from a central server can solve a lot of these issues without all the overhead and licensing , especially if you have special vendor application that ca n't run in a domain ( the vendor wo n't support it ) .</tokentext>
<sentencetext>Novel sells Zen, which does an LDAP domain like AD, hosted from Linux.
Yes there might be incompatibilities with Windows, but Windows typically has incompatibilities with Windows too.
Novel's stuff will probably support your UNIX systems better.
The admins I've met running Novel seemed happy with it, especially with the security features and invulnerability (low incidence)  to typical internet malware.Also, you are missing the point of LDAP and AD.
LDAP directory services can TALK TO EACH OTHER.
It's based on standards.
You can have a Linux-based LDAP forest talk to a Windows-based AD forest.
It will work.
There may/will be problems, but consider this:most of the time, your linux servers will deal with the linux LDAP servermost of the time, your windows servers will deal with the windows domainfile &amp; data transfers can also be done a variety of ways that don't involve directory services.
SSH with private key auth.
The HTTP your using now is another.If system administration is becoming a burden, you just need to automate more.
Write more scripts.
Work as a team to automate most tasks until you have less and less to do.
A perfect, orderly domain doesn't exist and may cause more problems than it solves.
Cron/scheduler that downloads new/updated scripts from a central server can solve a lot of these issues without all the overhead and licensing, especially if you have special vendor application that can't run in a domain (the vendor won't support it).</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28218429</id>
	<title>Re:Just go with AD</title>
	<author>lacourem</author>
	<datestamp>1244136180000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>+ 1 on the Likewise suggestion.  We pay them money and it really is worth the cost.  Our AD admin is not a linux guy, and the Likewise tool snaps right into the MMC AD Console.  This allowed him to get up to speed right away in an environment he was already comfortable with.</htmltext>
<tokenext>+ 1 on the Likewise suggestion .
We pay them money and it really is worth the cost .
Our AD admin is not a linux guy , and the Likewise tool snaps right into the MMC AD Console .
This allowed him to get up to speed right away in an environment he was already comfortable with .</tokentext>
<sentencetext>+ 1 on the Likewise suggestion.
We pay them money and it really is worth the cost.
Our AD admin is not a linux guy, and the Likewise tool snaps right into the MMC AD Console.
This allowed him to get up to speed right away in an environment he was already comfortable with.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213757</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28217215</id>
	<title>Thiago Barbanti</title>
	<author>Anonymous</author>
	<datestamp>1244123100000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>You can use too:</p><p>Apache Directory (http://directory.apache.org/)</p><p>Sun OpenDS (http://www.opends.org/)</p><p>today I have a job implementing a single sign-on solution to be integrated with system stuff of company, internally using OpenLDAP. But in my development process I am using Apache Directory as development platform to do this job at all and I see as good solution many because the manager application (Apache Directory Studio).</p></htmltext>
<tokenext>You can use too : Apache Directory ( http : //directory.apache.org/ ) Sun OpenDS ( http : //www.opends.org/ ) today I have a job implementing a single sign-on solution to be integrated with system stuff of company , internally using OpenLDAP .
But in my development process I am using Apache Directory as development platform to do this job at all and I see as good solution many because the manager application ( Apache Directory Studio ) .</tokentext>
<sentencetext>You can use too:Apache Directory (http://directory.apache.org/)Sun OpenDS (http://www.opends.org/)today I have a job implementing a single sign-on solution to be integrated with system stuff of company, internally using OpenLDAP.
But in my development process I am using Apache Directory as development platform to do this job at all and I see as good solution many because the manager application (Apache Directory Studio).</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28217067</id>
	<title>Either Linux or AD</title>
	<author>Anonymous</author>
	<datestamp>1244121960000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>If you're a Linux shop then either stay away from AD or throw Linux away.  AD is far from the best directory server, the value in AD comes in the non-directory aspects tying it into other Microsoft products.  If you're a Linux shop, then deploy a good directory service (e.g. FDS, OpenIPA, eDirectory) an tie the handful of Windows boxes into that infrastructure.</p></htmltext>
<tokenext>If you 're a Linux shop then either stay away from AD or throw Linux away .
AD is far from the best directory server , the value in AD comes in the non-directory aspects tying it into other Microsoft products .
If you 're a Linux shop , then deploy a good directory service ( e.g .
FDS , OpenIPA , eDirectory ) an tie the handful of Windows boxes into that infrastructure .</tokentext>
<sentencetext>If you're a Linux shop then either stay away from AD or throw Linux away.
AD is far from the best directory server, the value in AD comes in the non-directory aspects tying it into other Microsoft products.
If you're a Linux shop, then deploy a good directory service (e.g.
FDS, OpenIPA, eDirectory) an tie the handful of Windows boxes into that infrastructure.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214817</id>
	<title>Re:Easy</title>
	<author>ogrius</author>
	<datestamp>1244109180000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext><p>The other thing you can consider is whether to split the directory services and the authentication.</p><p>At my last job we did the following:</p><p>- Use Windows AD for all windows machines<br>- Use NIS for passwd, group, automounter maps... everything but authentication.<br>- And then key the Linux machines to use Kerberos off the Active Directory</p><p>Now if I was doing it again, I'd do the following:</p><p>- Use Windows AD for all windows machines<br>- Setup up a UNIX/Linux based Kerberos domain that "trusted" by the AD Kerberos<br>- Use NIS, NIS+ or LDAP from Windows AD for directory services for UNIX/Linux</p><p>- Setup all the UNIX/Linux machines on the UNIX/Linux Kerberos domain and have them use the windows domain for user authentication.</p><p>The adavantage to this would be that once you have a valid ticket you can securely log into any of the machines. Plus then you could securely setup NFS v4.</p><p>As for which NIS, NIS+ or LDAP to use, I haven't looked into recently.</p><p>And why I would use two Kerberos domains is that the Windows AD says it should play nice with Linux machines and allow you at keys onto them. But the commands from Microsoft never worked. I used a simple utility from some consulting company that worked well, but it wasn't supported and there it seemed to be hitting some hard limits. Since I'd hate to wait for Microsoft to fix their setup, I'd use two domains but setup a trust between them.</p></htmltext>
<tokenext>The other thing you can consider is whether to split the directory services and the authentication.At my last job we did the following : - Use Windows AD for all windows machines- Use NIS for passwd , group , automounter maps... everything but authentication.- And then key the Linux machines to use Kerberos off the Active DirectoryNow if I was doing it again , I 'd do the following : - Use Windows AD for all windows machines- Setup up a UNIX/Linux based Kerberos domain that " trusted " by the AD Kerberos- Use NIS , NIS + or LDAP from Windows AD for directory services for UNIX/Linux- Setup all the UNIX/Linux machines on the UNIX/Linux Kerberos domain and have them use the windows domain for user authentication.The adavantage to this would be that once you have a valid ticket you can securely log into any of the machines .
Plus then you could securely setup NFS v4.As for which NIS , NIS + or LDAP to use , I have n't looked into recently.And why I would use two Kerberos domains is that the Windows AD says it should play nice with Linux machines and allow you at keys onto them .
But the commands from Microsoft never worked .
I used a simple utility from some consulting company that worked well , but it was n't supported and there it seemed to be hitting some hard limits .
Since I 'd hate to wait for Microsoft to fix their setup , I 'd use two domains but setup a trust between them .</tokentext>
<sentencetext>The other thing you can consider is whether to split the directory services and the authentication.At my last job we did the following:- Use Windows AD for all windows machines- Use NIS for passwd, group, automounter maps... everything but authentication.- And then key the Linux machines to use Kerberos off the Active DirectoryNow if I was doing it again, I'd do the following:- Use Windows AD for all windows machines- Setup up a UNIX/Linux based Kerberos domain that "trusted" by the AD Kerberos- Use NIS, NIS+ or LDAP from Windows AD for directory services for UNIX/Linux- Setup all the UNIX/Linux machines on the UNIX/Linux Kerberos domain and have them use the windows domain for user authentication.The adavantage to this would be that once you have a valid ticket you can securely log into any of the machines.
Plus then you could securely setup NFS v4.As for which NIS, NIS+ or LDAP to use, I haven't looked into recently.And why I would use two Kerberos domains is that the Windows AD says it should play nice with Linux machines and allow you at keys onto them.
But the commands from Microsoft never worked.
I used a simple utility from some consulting company that worked well, but it wasn't supported and there it seemed to be hitting some hard limits.
Since I'd hate to wait for Microsoft to fix their setup, I'd use two domains but setup a trust between them.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213723</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28219987</id>
	<title>Re:Start with SQL</title>
	<author>dregs</author>
	<datestamp>1244200620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>omg, its takien us 7 years to undo this sort simple to setup, difficult to protect system.<br>Once the auditors found it, it was year after year of explaining that 10\% of systems have been moved off the plain text passwords, then 25\% then 50\%, etc</p><p>My advice, only ever do this, if you are not securing anything scure, and you will never have to face an security audit board.<nobr> <wbr></nobr>..</p></htmltext>
<tokenext>omg , its takien us 7 years to undo this sort simple to setup , difficult to protect system.Once the auditors found it , it was year after year of explaining that 10 \ % of systems have been moved off the plain text passwords , then 25 \ % then 50 \ % , etcMy advice , only ever do this , if you are not securing anything scure , and you will never have to face an security audit board .
. .</tokentext>
<sentencetext>omg, its takien us 7 years to undo this sort simple to setup, difficult to protect system.Once the auditors found it, it was year after year of explaining that 10\% of systems have been moved off the plain text passwords, then 25\% then 50\%, etcMy advice, only ever do this, if you are not securing anything scure, and you will never have to face an security audit board.
..</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214365</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213913</id>
	<title>My choices</title>
	<author>xaoslaad</author>
	<datestamp>1244148000000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext>1.) RHDS - Red Hat Directory Server<br>
2.) Active Directory<br>
3.) OpenLDAP <br>
4.) Novell eDirectory (personally my least favorite)<br>
<br>
I would probably jump for RHDS first, then AD. The only problem with OpenLDAP might be getting a similar level of support to the first two. Support is exactly why I would never choose eDirectory. I have (personally) had abysmal experiences dealing with Novell. Others may disagree though. And of course there probably are other options.</htmltext>
<tokenext>1 .
) RHDS - Red Hat Directory Server 2 .
) Active Directory 3 .
) OpenLDAP 4 .
) Novell eDirectory ( personally my least favorite ) I would probably jump for RHDS first , then AD .
The only problem with OpenLDAP might be getting a similar level of support to the first two .
Support is exactly why I would never choose eDirectory .
I have ( personally ) had abysmal experiences dealing with Novell .
Others may disagree though .
And of course there probably are other options .</tokentext>
<sentencetext>1.
) RHDS - Red Hat Directory Server
2.
) Active Directory
3.
) OpenLDAP 
4.
) Novell eDirectory (personally my least favorite)

I would probably jump for RHDS first, then AD.
The only problem with OpenLDAP might be getting a similar level of support to the first two.
Support is exactly why I would never choose eDirectory.
I have (personally) had abysmal experiences dealing with Novell.
Others may disagree though.
And of course there probably are other options.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28224539</id>
	<title>Enterprise directory services</title>
	<author>LDAPMAN</author>
	<datestamp>1244224740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>There is no ONE directory services that is optimum for every use case. If you want to manage large numbers of Windows workstations then you need AD. If you want to do high performance LDAP then you need eDirectory. If you want to manage authentication to Oracle DBs the you need OID....the list goes on.   This is why for any non-trivial implementation you need Novell Identity Manager which allows you to use the right service directory for each of these applications but enables you to manage your environment as if it was a single homogeneous directory.

Note...I design such systems for the largest environments in the world.  The largest production implementation I've worked on is in excess of 400 million identities.</htmltext>
<tokenext>There is no ONE directory services that is optimum for every use case .
If you want to manage large numbers of Windows workstations then you need AD .
If you want to do high performance LDAP then you need eDirectory .
If you want to manage authentication to Oracle DBs the you need OID....the list goes on .
This is why for any non-trivial implementation you need Novell Identity Manager which allows you to use the right service directory for each of these applications but enables you to manage your environment as if it was a single homogeneous directory .
Note...I design such systems for the largest environments in the world .
The largest production implementation I 've worked on is in excess of 400 million identities .</tokentext>
<sentencetext>There is no ONE directory services that is optimum for every use case.
If you want to manage large numbers of Windows workstations then you need AD.
If you want to do high performance LDAP then you need eDirectory.
If you want to manage authentication to Oracle DBs the you need OID....the list goes on.
This is why for any non-trivial implementation you need Novell Identity Manager which allows you to use the right service directory for each of these applications but enables you to manage your environment as if it was a single homogeneous directory.
Note...I design such systems for the largest environments in the world.
The largest production implementation I've worked on is in excess of 400 million identities.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213703</id>
	<title>Step 1.</title>
	<author>Anonymous</author>
	<datestamp>1244147220000</datestamp>
	<modclass>Flamebait</modclass>
	<modscore>-1</modscore>
	<htmltext>Scrap the Windows boxes.</htmltext>
<tokenext>Scrap the Windows boxes .</tokentext>
<sentencetext>Scrap the Windows boxes.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28218781</id>
	<title>Re:Novell.......no seriously</title>
	<author>drinkypoo</author>
	<datestamp>1244140260000</datestamp>
	<modclass>Flamebait</modclass>
	<modscore>-1</modscore>
	<htmltext><p>Novell is in bed with Microsoft now, so if you're going to pay for a Novell product you might as well just run Windows and AD.</p></htmltext>
<tokenext>Novell is in bed with Microsoft now , so if you 're going to pay for a Novell product you might as well just run Windows and AD .</tokentext>
<sentencetext>Novell is in bed with Microsoft now, so if you're going to pay for a Novell product you might as well just run Windows and AD.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213799</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28258219</id>
	<title>Re:FreeIPA, Apple OD, Gosa2, Novell eDirectory, FD</title>
	<author>Anonymous</author>
	<datestamp>1244461920000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Try OpenDS as well.</p></htmltext>
<tokenext>Try OpenDS as well .</tokentext>
<sentencetext>Try OpenDS as well.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214801</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214393</id>
	<title>Re:Just go with AD</title>
	<author>Anonymous</author>
	<datestamp>1244106960000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>1</modscore>
	<htmltext><p>The main pitfall is to be careful about the MS licensing rules for AD. You essentially need a CAL for EVERY USER in your directory, or some of the crazy very expensive CALs. This is no big deal if you already have CALs, but it would be insane to use AD for something where the users accessing the server are not employees of your company. The licensing costs would become crazy when compared with something open source.</p></htmltext>
<tokenext>The main pitfall is to be careful about the MS licensing rules for AD .
You essentially need a CAL for EVERY USER in your directory , or some of the crazy very expensive CALs .
This is no big deal if you already have CALs , but it would be insane to use AD for something where the users accessing the server are not employees of your company .
The licensing costs would become crazy when compared with something open source .</tokentext>
<sentencetext>The main pitfall is to be careful about the MS licensing rules for AD.
You essentially need a CAL for EVERY USER in your directory, or some of the crazy very expensive CALs.
This is no big deal if you already have CALs, but it would be insane to use AD for something where the users accessing the server are not employees of your company.
The licensing costs would become crazy when compared with something open source.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213757</parent>
</comment>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_04_1911206_22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28258219
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214801
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_04_1911206_16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214595
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213723
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_04_1911206_13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28217095
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214343
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213723
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_04_1911206_10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28219171
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213799
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_04_1911206_26</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214341
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213913
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_04_1911206_14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28217065
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214249
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213757
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_04_1911206_17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214931
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213723
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_04_1911206_11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28217459
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214011
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_04_1911206_18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28217823
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214393
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213757
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_04_1911206_1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28217673
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214343
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213723
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_04_1911206_15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28228127
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213799
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_04_1911206_19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28219007
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214365
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_04_1911206_5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28228161
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214011
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_04_1911206_23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28219337
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213913
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_04_1911206_9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214817
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213723
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_04_1911206_2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28219987
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214365
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_04_1911206_6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28222423
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213913
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_04_1911206_27</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28224905
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214365
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_04_1911206_3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28218429
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213757
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_04_1911206_21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28215915
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214249
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213757
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_04_1911206_7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28217905
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214343
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213723
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_04_1911206_0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28224755
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214727
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_04_1911206_4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28217445
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214335
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213913
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_04_1911206_20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28219273
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214335
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213913
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_04_1911206_25</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28217423
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213913
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_04_1911206_24</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214935
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213777
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_04_1911206_12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28218781
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213799
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_04_1911206_8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28217341
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214161
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_04_1911206_29</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28217161
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214801
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_04_1911206_28</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213951
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213723
</commentlist>
</thread>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_04_1911206.9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213777
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214935
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_04_1911206.3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213913
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28222423
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214335
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28219273
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28217445
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214341
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28217423
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28219337
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_04_1911206.1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28217059
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_04_1911206.14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213757
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28218429
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214249
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28215915
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28217065
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214393
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28217823
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_04_1911206.4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214827
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_04_1911206.12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28224539
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_04_1911206.7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213723
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213951
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214343
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28217905
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28217095
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28217673
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214931
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214595
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214817
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_04_1911206.18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214011
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28228161
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28217459
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_04_1911206.2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213751
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_04_1911206.5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28215047
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_04_1911206.16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214801
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28258219
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28217161
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_04_1911206.0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214161
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28217341
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_04_1911206.8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213925
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_04_1911206.13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214461
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_04_1911206.6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214727
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28224755
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_04_1911206.10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28213799
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28218781
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28228127
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28219171
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_04_1911206.11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214571
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_04_1911206.17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28216247
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_04_1911206.15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28214365
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28219987
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28219007
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_04_1911206.28224905
</commentlist>
</conversation>
