If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Samba 4.0 Dances Closer To Release

01-26-2012, 03:40 PM

Phoronix: Samba 4.0 Dances Closer To Release

After a very long and exhausting development process that's been going on since 2003, while simultaneously developing the Samba 3.x series, Samba 4.0 is dancing closer to an official release this year...

I can't wait Samba4 stable comes out. I have a lot of samba primary domain controllers around (that work perfectly) but it's time to change to a Active Directory since it's way more advanced. The fact it has an internal ldap and kerberos server is just great.

Good work samba team!

Comment

I can't wait Samba4 stable comes out. I have a lot of samba primary domain controllers around (that work perfectly) but it's time to change to a Active Directory since it's way more advanced. The fact it has an internal ldap and kerberos server is just great.

Good work samba team!

If the Samba folks can successfully pull off an Active Directory domain controller that integrates properly with Windows servers, it will be quite an accomplishment.

Having said that(and being an Active Directory SME), I really don't think that's the way forward.

If anybody feels like developing "the future"(tm), here's my idea for Linux networking that I never have time to start because of my other 3 software projects:

1. A LDAP server that serves user tokens via Apache and SOAP, based on a real database backend like PostgreSQL, with a db schema that isn't completely stupid(like AD), with proper indexing for fast searches(unlike AD). This also creates a perfect SSO system for web applcations.
2. A login client for authenticating Windows machines.
3. A login client for authenticating *NIX machines
4. An API to authenticate other applications SSO style.
5. An FTP share system that uses it, so people can stop using SMB/CIFS shares, and just install a modded Filezilla like application to share files on the network.

Somebody please steal this idea from me, a highly motivated and skilled developer could probably write it all in a month with enough coffee.

Comment

If the Samba folks can successfully pull off an Active Directory domain controller that integrates properly with Windows servers, it will be quite an accomplishment.

Having said that(and being an Active Directory SME), I really don't think that's the way forward.

If anybody feels like developing "the future"(tm), here's my idea for Linux networking that I never have time to start because of my other 3 software projects:

1. A LDAP server that serves user tokens via Apache and SOAP, based on a real database backend like PostgreSQL, with a db schema that isn't completely stupid(like AD), with proper indexing for fast searches(unlike AD). This also creates a perfect SSO system for web applcations.
2. A login client for authenticating Windows machines.
3. A login client for authenticating *NIX machines
4. An API to authenticate other applications SSO style.
5. An FTP share system that uses it, so people can stop using SMB/CIFS shares, and just install a modded Filezilla like application to share files on the network.

Somebody please steal this idea from me, a highly motivated and skilled developer could probably write it all in a month with enough coffee.

Nobody is going to even come close to finishing that in a month even if you discount testing entirely. Having said that, if someone is looking for alternatives, http://freeipa.org/ might be of interest.

Comment

If the Samba folks can successfully pull off an Active Directory domain controller that integrates properly with Windows servers, it will be quite an accomplishment.

Having said that(and being an Active Directory SME), I really don't think that's the way forward.

If anybody feels like developing "the future"(tm), here's my idea for Linux networking that I never have time to start because of my other 3 software projects:

1. A LDAP server that serves user tokens via Apache and SOAP, based on a real database backend like PostgreSQL, with a db schema that isn't completely stupid(like AD), with proper indexing for fast searches(unlike AD). This also creates a perfect SSO system for web applcations.
2. A login client for authenticating Windows machines.
3. A login client for authenticating *NIX machines
4. An API to authenticate other applications SSO style.
5. An FTP share system that uses it, so people can stop using SMB/CIFS shares, and just install a modded Filezilla like application to share files on the network.

Somebody please steal this idea from me, a highly motivated and skilled developer could probably write it all in a month with enough coffee.

What you are describing is easy if you just assume all of your components can be trusted, which is very naive. In order to have a secure authentication system, all components must have explicit trust defined and be able to audit transactions at any point. This is why standards like Kerberos exist. Microsoft actually did a very respectable job in their AAA implementation in AD.

Comment

What you are describing is easy if you just assume all of your components can be trusted, which is very naive

Ummmm, Active Directory is wide open, any authenticated user can query the directory(which is why you should never store sensitive information in it), and OUs, Domains, Forests can only be modified by users with sufficient rights to do so, as defined in the individual directory. There is nothing complicated about implementing that, and trust can easily be thrown in by leveraging existing certificate authority setups.

To all of the haters, I present to you, the 30-day, 1-developer Active Directory replacement cycle:

Day 1: Implement an LDAP schema in your database of choice. Too easy.
Days 2 through 4: Write the Apache/SOAP/HTTPS server for serving authentication requests and queries. Could probably be done in 500 to 1000 lines of PHP.
Days 5 through 7: Write a PHP API for authenticating web users SSO style and getting either a list of user groups from an authentication request, or returning the results of a generic query. Could probably be done in 500 lines of PHP. Other languages can come later.
Days 8 through 10: Write a library to query the directory and parse the results. libcurl and tinyxml already cover 90% of what you need, there would probably only be 300 lines of code.
Days 11 through 12: Pick an existing FOSS login client for Windows and Linux, and modify it to use the library you wrote for authentication. It's probably a matter of replacing a single function.
Days 13 through 14: Implement a certificate authority for the domain controller using existing FOSS code, in order to define which machines are part of the domain
Days 15 through 20: Domain controller replication. Shouldn't be too hard if you picked your database well.
Days 21 through 30: Quality control, writing automated tests.

Nobody is going to even come close to finishing that in a month even if you discount testing entirely. Having said that, if someone is looking for alternatives, http://freeipa.org/ might be of interest.

Now, mind you, when I said "finished in 30 days" I didn't mean that it would be 100% ready to be mainlined into the next release of RHEL at this point, but it could certainly be driving a virtual network of 5 or VMs running on my developer's workstation. Frankly, the biggest thing holding me back from doing it is that I don't want to waste my time if no major distros are going to adopt it, and it's a bit difficult to ask them to support something I haven't written yet; the chicken or egg, which came first? paradigm.

EDIT: I forgot to include an administration interface. Take 3 days out of QC to write a basic one, the super advanced slick one with javascript animations and flash video can come later.

Comment

Ummmm, Active Directory is wide open, any authenticated user can query the directory(which is why you should never store sensitive information in it), and OUs, Domains, Forests can only be modified by users with sufficient rights to do so, as defined in the individual directory. There is nothing complicated about implementing that, and trust can easily be thrown in by leveraging existing certificate authority setups.

Active Directory LDAP is "wide open." Big deal. Nothing private is stored in LDAP. Authentication data is not stored in AD LDAP. Authentication is handled by Kerberos, which was designed for the expressed purpose of authentication and establishing trust.

Also, Using PKI would only establish implicit trust of a connection; trust is not established at the authentication protocol level. Since certificate validation occurs in a different layer, your system would have to take the word of yet another component that everything is "on the level." Not that it is entirely invalid to do this, but it does not achieve the level of trust a good authentication requires.

To all of the haters, I present to you, the 30-day, 1-developer Active Directory replacement cycle:

Day 1: Implement an LDAP schema in your database of choice. Too easy.
Days 2 through 4: Write the Apache/SOAP/HTTPS server for serving authentication requests and queries. Could probably be done in 500 to 1000 lines of PHP.
Days 5 through 7: Write a PHP API for authenticating web users SSO style and getting either a list of user groups from an authentication request, or returning the results of a generic query. Could probably be done in 500 lines of PHP. Other languages can come later.
Days 8 through 10: Write a library to query the directory and parse the results. libcurl and tinyxml already cover 90% of what you need, there would probably only be 300 lines of code.
Days 11 through 12: Pick an existing FOSS login client for Windows and Linux, and modify it to use the library you wrote for authentication. It's probably a matter of replacing a single function.
Days 13 through 14: Implement a certificate authority for the domain controller using existing FOSS code, in order to define which machines are part of the domain
Days 15 through 20: Domain controller replication. Shouldn't be too hard if you picked your database well.
Days 21 through 30: Quality control, writing automated tests.

The only 2 parts that have a real potential for failure are:
1. The developer sucks at developing database schemas
2. The developer sucks at developing secure PHP applications

Now, mind you, when I said "finished in 30 days" I didn't mean that it would be 100% ready to be mainlined into the next release of RHEL at this point, but it could certainly be driving a virtual network of 5 or VMs running on my developer's workstation. Frankly, the biggest thing holding me back from doing it is that I don't want to waste my time if no major distros are going to adopt it, and it's a bit difficult to ask them to support something I haven't written yet; the chicken or egg, which came first? paradigm.

I am reminded of Fry in the Futurama episode "Why Must I Be a Crustacean in Love?". [Paraphrased] Fry: I can have any girl I want... I'm just too busy.

If you could implement your system, people would pay you large sums of money to implement it and continue working on it; open-source or not. MIT would give you an honorary doctorate. You would have your pick of any employer on the planet.

I will end with a Stephen King quote: "Money talks. Bullshit walks." I smell bullshit.

Comment

I am reminded of Fry in the Futurama episode "Why Must I Be a Crustacean in Love?". [Paraphrased] Fry: I can have any girl I want... I'm just too busy.

If you could implement your system, people would pay you large sums of money to implement it and continue working on it; open-source or not. MIT would give you an honorary doctorate. You would have your pick of any employer on the planet.

I will end with a Stephen King quote: "Money talks. Bullshit walks." I smell bullshit.

BWHAHAHAHAHAHAHAH!!!!

I take it you're not an open source developer, and don't know how these things work.

I had no intention of boasting, and I believe there are many open source developers that could put this together quickly with the right strategy, and by leveraging existing open source libraries and applications. It could be done with very few lines of code, which makes it much easier.

"If you could implement your system, people would pay you large sums of money to implement it and continue working on it;"

LMFAO, no, most open source software doesn't pay much of anything, even big important projects. If that's your expectation, don't ever become a developer.

"MIT would give you an honorary doctorate."

Trying to be a little dramatic, are you?

"You would have your pick of any employer on the planet."

I already do, but IT geeks are also in serious demand, so I'm not the only one.

Comment

Perhaps I am being a little dramatic, but in all seriousness, a system like you propose would be "the next big thing." You would literally become the next Steve Wozniak, Linus Torvalds, Tim Berners-Lee.

Secure inter-system communication and authentication among homogenous systems is still a big pain-in-the-ass in todays world.

Of course, the real question is not if a system like you propose could work, it is if it could work securely. Having more than just a basic understanding of the problem, I can say with almost 100% certainty, that it cannot. I think it would end up being the swiss cheese of authentication systems.

My main point is that if you think you can do it... then do it. There is no other project you are working on that could possibly have the implications and importance as this.

In other words... show me the money.

Comment

Perhaps I am being a little dramatic, but in all seriousness, a system like you propose would be "the next big thing." You would literally become the next Steve Wozniak, Linus Torvalds, Tim Berners-Lee.

Once again, I admire your spirit, but things rarely ever work out that way. It all comes down to whether people actually decide to use it or not, and that's not guaranteed. I'm sure that the Samba folks thought they would've taken over the world by now, but it obviously hasn't happened yet. The problem is that rather than trying to innovate, they tried to chase the moving target that is Windows, with binary level compatibility... It's destined for failure the same way WINE is. I recently evaluated running some business applications in Wine using a Ubuntu LTSP server. Only one out of five worked, absolutely dismal considering the WINE project has like 10,000 developers and trillions of dollars. The open source community can only win by out-innovating Windows with native applications, Firefox and Chrome being fine examples.

Secure inter-system communication and authentication among homogenous systems is still a big pain-in-the-ass in todays world.

Of course, the real question is not if a system like you propose could work, it is if it could work securely. Having more than just a basic understanding of the problem, I can say with almost 100% certainty, that it cannot. I think it would end up being the swiss cheese of authentication systems.

Is Apache secure? Is SSL secure? Is PHP secure? Is PostgreSQL or MySQL secure? Are Linux CAs secure? Is BIND secure? Yes? Then my idea would also be secure. Rather than trying to go writing a sockets-level protocol from scratch, why not leverage some very mature web-server code to do the same thing? It's almost scary just how little code it would take to write it, because it's mostly leveraging a mature stack of existing apps.

My main point is that if you think you can do it... then do it. There is no other project you are working on that could possibly have the implications and importance as this.

Actually, it just might... If you want to write it, I'll gladly provide guidance... If not, I expect my current project I'm focused on to be at a good stopping point in 6 to 12 months, and then I may consider coming back to this idea. I really wish somebody would do something like this, which was my whole reason for sharing it here in the first place. I want to see FOSS win, and projects like Samba and WINE are never going to do that.