passwd just uses PAM. Configure PAM to send password changes to LDAP.
Add the following to /etc/pam.d/common-password
password sufficient pam_ldap.so try_first_pass
password required pam_unix.so nullok obscure min=4 max=8 md5 try_first_pass
This assumes that you've already configured LDAP to allow the necessary writes and the only thing lacking is the PAM set up.
The short answer:
Variables do not take double the space in 64-bit vs 32-bit software. The potential memory gain from switching to a 32-bit OS will not be worth the effort.
The long answer:
Numbers can be larger yes, but that doesn't mean they will be. Also this applies to numbers, not strings, and strings are (generally) what consume the most amount of memory in an application.
Additionally, many applications explicitly specify the size of the number they want to work with, as in languages like C, int can be any size, including smaller than 32-bit. And going even further, on my 64-bit Linux machine, in C int is 32-bit. So you would have to explicitly request long long to get a 64-bit number.
So basically, applications aren't going to use more memory just because they were compiled for 64-bit.
EDIT:
In response to Gilles' claim that 64-bit Firefox uses twice as much memory, I went and did a comparison between 32-bit and 64-bit Firefox on my system.
I tested by launching 5 tabs open to http://acid3.acidtests.org/ and performed the test 3 times (once in 32-bit, once in 64-bit, and then repeat twice). I chose this site because it's JavaScript intensive, and uses static content (each rendering of the page will provide the same data).
On the final run:
32-bit: 173,244kb rss / 918,348kb virt
64-bit: 184,588kb rss / 966,624kb virt
I could do more extensive testing yes, but I think this demonstrates well enough that the size difference between the two is marginal.
Best Answer
To answer your last question first, x86-64 CPUs (a.k.a. Intel 64, AMD64, x64...; basically any laptop/desktop 64-bit CPU you can get these days) are fully backwards-compatible with 32-bit operating systems and applications. So a 32-bit OS will work on a modern desktop.
As to why you should use 64-bit instead, the 64-bit instruction set adds various features which allow compilers to generate faster code (notably, there are more registers and they can store far more values), so the same application built for x86-64 will often run faster than when it is built for 32-bit mode on the same CPU. This does come at the cost of using more memory for pointers, but the speed increase usually outweighs the pointer cost.
For far more information on all this, check out Wikipedia. You may also be interested in x32 which enables 32-bit software to use the speed-enhancing features of 64-bit CPUs without the pointer cost (but they only run on 64-bit CPUs); Wikipedia also has details.