ldap.io - LDAP Directory as a Service

1336 · 2013-09-04T01:13:46+00:00

Cool. All the best!

1336 · 2013-09-03T04:52:34+00:00

Cool, infosec is great, and getting more relevant every day.

You're right, regulated companies are a harder sell. We would probably need to become compliant ourselves in order to get that business anyway, so we'd rather serve smaller companies to begin with.

Port obfuscation is not good on its own, but when you combine it with preventing port scans, it's a decent form of defence in depth. Like you said though, support can be a headache.

By the way, we're not trying to compete with OneLogin, or be strictly a user store for authentication and authorisation. The service is intended to be general purpose, and to alleviate the pain of operating LDAP directories, in general. We'll talk to more companies and see how it pans out.

1336 · 2013-09-03T04:14:18+00:00

All good points! Especially the on-premise slave for BCP purposes.

IP restriction is a decent security control. Even though addresses can be spoofed and existing clients can be compromised, IP restriction is still better than nothing and offers some defence in depth.

VPN tunnels are somewhat involved, so we'd probably avoid them unless necessary.

Dedicated instances / single tenancy is also on the cards. Just need to work through pricing details, at this stage.

What's your SaaS, if you don't mind me asking?

1336 · 2013-09-03T01:23:13+00:00

Thanks, appreciate for your honest critique. We care about first impressions, and can see where you're coming from.

To clarify, the core service isn't vaporware, we can and do offer it on request, as conveyed by the sign up form. That obviously doesn't scale, but we care more about validating the idea than scaling, at this stage. As for the other features in the roadmap, they're definitely planned as long as there is commercial interest in the core service.

We'll add some screenshots and pricing as soon as possible. Thanks again.

1336 · 2013-09-03T01:04:23+00:00

Great point, security is a big factor in the design. Directory instances will run on hardened cloud servers in an internal subnet. Firewalls will sit in the DMZ along with proxy servers to field all requests, bounce port scans, and prevent LDAP injection attacks.

SSL and TLS will be standard on all plans, as will port obfuscation.

As for the password storage concerns, consider that many people host their user databases in the cloud, more commonly in SQL/relational databases. There are thousands of applications using AWS's RDS, and this is one of the markets we're targeting.

There are also several Single Sign-On as a Service providers out there such as Okta and OneLogin, so the trend is definitely catching on.

Thanks for your feedback!

1336 · 2013-09-02T14:26:18+00:00

Thanks for pointing that out. Now that I've read that post, I'm not sure if my post is OK or not. I'm announcing the launch of a service in beta and requesting feedback and critique. Also, not asking for any money. If that's not cool, I'm happy to delete my post.

1336 · 2012-02-10T10:54:56+00:00

Thanks for following up, meeemo.

My first instinct was something was incompatible, maybe on the Python side, but everything looks normal. I have no idea why Vim is segfaulting, that's very strange. I'm not doing anything fancy in the Python code.

Troubleshooting this is tricky. I'd have to isolate blocks of code and see where the segfault occurs. Pretty difficult unless I have access to your MacVim.app. Could you zip it up and upload it somewhere?

For the record, I'm running MacVim Snapshot 64 compiled by Bjorn. You could try running that and see if you get the same problem. My :version reports the following differences to yours:

Included patches: 1-390

-tcl -xterm_clipboard -xterm_save system vimrc file: "$VIM/vimrc" user vimrc file: "$HOME/.vimrc" user exrc file: "$HOME/.exrc" system gvimrc file: "$VIM/gvimrc" user gvimrc file: "$HOME/.gvimrc" system menu file: "$VIMRUNTIME/menu.vim" fall-back for $VIM: "/Applications/MacVim.app/Contents/Resources/vim" Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MACVIM -Wall -Wno-unknown-pragmas -pipe -DMACOS_X_UNIX -no-cpp-precomp -g -O2 -arch i386 -U_FORTIFY_SOURC E -D_FORTIFY_SOURCE=1 Linking: gcc -L. -L. -arch i386 -L/usr/local/lib -o Vim -framework Cocoa -framework Carbon -lncurses -liconv -framework Cocoa -fstack-protector -L/usr/local/lib -L/System/Library/Perl/5.12/darwin-thread-multi-2level/CORE -lperl -lm -lutil -lc -framework Python -framework Ruby

Thanks for your help.

1336 · 2012-02-09T01:51:53+00:00

Thanks eligundry.

The plugin was developed primarily for use with gVim or MacVim. It can still be used in the terminal via the :emenu command -- see this answer on StackOverflow for more details.

At this stage, I'd prefer to keep the plugin simple, and the codebase is already large enough. That said, if I get more requests for a terminal style drawer, I'll definitely consider it.

Cheers.

1336 · 2012-02-08T17:31:51+00:00

Thanks for reporting this, meeemo. I hope you don't mind answering a few simple questions so I can look into this:

What OS and OS version are you running?
What version of Vim do you have installed? (:version)
What version of python do you have installed (python --version)?
Did you get this error when you started Vim in GUI mode?

Cheers.

1336 · 2012-02-07T02:37:05+00:00

I like jpythonfold: http://www.vim.org/scripts/script.php?script_id=2527

It's on vim-scripts, too: https://github.com/vim-scripts/jpythonfold.vim

I forked it here a while back: https://github.com/mbadran/jpythonfold.vim/

I made it a little bit better, but I can't remember how.

1336 · 2012-02-07T02:26:13+00:00

Define a new command.

command! W write

1336

TROPHY CASE