Not entirely sure of your question. I'd think exposing your ldap service to the open internet is asking for very very bad things to happen.
I'd expect a service like this would use Amazon VPC, a secure VPN to access it, or something like that. What kind of data do you envision being stored in this directory, user credentials, or other things?
At $last_job, I was on a mission to put everything in LDAP. There is a custom OpenLDAP schema that the gnome.org sysadmin team (which I am an alumni member of) which allowed users to put in their ssh pub key via a webui. Hosts then run a cronjob every XX time period that put those ssh keys down (in a root owned directory/file so users can't change them), and was pretty slick. I also put DNS zone info and sudoers information into LDAP, as I already had a badass distributed datastore, ldap :)
That being said, can you come up with a real use case where your service makes sense? Active Directory is hard to compete against, it is super cheap and a pretty solid kerberized ldap for SMBs.
I'd expect a service like this would use Amazon VPC, a secure VPN to access it, or something like that. What kind of data do you envision being stored in this directory, user credentials, or other things?
At $last_job, I was on a mission to put everything in LDAP. There is a custom OpenLDAP schema that the gnome.org sysadmin team (which I am an alumni member of) which allowed users to put in their ssh pub key via a webui. Hosts then run a cronjob every XX time period that put those ssh keys down (in a root owned directory/file so users can't change them), and was pretty slick. I also put DNS zone info and sudoers information into LDAP, as I already had a badass distributed datastore, ldap :)
That being said, can you come up with a real use case where your service makes sense? Active Directory is hard to compete against, it is super cheap and a pretty solid kerberized ldap for SMBs.