Changing the user's shell only "definitely" changes what gets executed if they attempt to log in and start a shell. It does not by itself invalidate access. So, someone might be able to run
ssh host -t /bin/sh in order to run a command, or might still be able to log in via ftp or a web app using this repository.
You could make this work, however, by checking for a valid login shell before allowing access. You could do this with an LDAP filter. Or, on most Linux systems (and several other PAM-enabled UNIX variants), you could use something like pam_shells, which checks to see if the user's shell is listed in /etc/shells before allowing access.
Traditionally, shell-based login access is done by either setting the shell to /bin/false or setting it to /bin/nologin (if it exists). Using pam_shells or an LDAP filter renders those solutions "mostly" pointless. However, I like to put /bin/true in /etc/shells so that I can discourage shell access for some users while allowing them in with something like scp; I then put /bin/false in for users who shouldn't get any of those, and use pam_shells on the services where I want to use the shell to switch things.
Most of the time, with LDAP you can provide an attribute which controls access. With Linux pam_ldap, the "pam_check_service_attr" option allows you to list specific pam services to which this user can authenticate (using the "authorizedService" attribute). There's also a host-based access attribute.
But really, the answer to your question depends very strongly on the capabilities of the software with which you're connecting to LDAP. :)