A more secure solution than that proposed by SvenW, and one that is more in keeping with the Apple way of doing things, is to add the password to the keychain. Here's how you would do it for an AFP share (I assume all you'd need to do is change the protocol specified by the -r option but I don't have the possibility of testing this with SMB right now; note that the whitespace in "afp " is intentional and necessary and I've only used this in a 10.6 environment):
sudo security add-internet-password -a "username_here" -D "Network Password" -r "afp " -l "cifs_share" -s "myserver.com" -p "cifs_share" -w "password_here" -T "/System/Library/CoreServices/NetAuthAgent.app/Contents/MacOS/NetAuthAgent"
Here's the relevant part of the man page for the security command:
add-internet-password [-h] [-a account] [-s server] [-w password] [options...] [keychain]
Add an internet password item.
-a account Specify account name (required)
-c creator Specify item creator (optional four-character code)
-C type Specify item type (optional four-character code)
-d domain Specify security domain string (optional)
-D kind Specify kind (default is "application password")
-j comment Specify comment string (optional)
-l label Specify label (if omitted, service name is used as default label)
-p path Specify path string (optional)
-P port Specify port number (optional)
-r protocol Specify protocol (optional four-character SecProtocolType, e.g. "http", "ftp ")
-s server Specify server name (required)
Specify authentication type (as a four-character SecAuthenticationType, default is "dflt")
-w password Specify password to be added
-A Allow any application to access this item without warning (insecure, not recommended!)
-T appPath Specify an application which may access this item (multiple -T options are allowed)
-U Update item if it already exists (if omitted, the item cannot already exist)
By default, the application which creates an item is trusted to access its data without warning. You can remove this default access
by explicitly specifying an empty app pathname: -T "". If no keychain is specified, the password is added to the default keychain.
The same thing should work for an SMB share, but note that the mechanism for matching keychain entries is quite particular (e.g. requiring that odd whitespace in the protocol name), so you need to test and be precise about how you store the password. When I first used this approach, I found that in order to get the paramaters right, it helped to first create the password in the keychain via the GUI (i.e. mount the share in the Finder and tick the box to save the authentication credentials to the keychain) and work backwards by examining the resulting entry in the keychain.
As noted by SvenW, the keychain needs to be unlocked for this approach to work, but that should happen automatically when the user logs in and should not be a problem based on your description. I'd also like to confirm that Kerberos does indeed work in 10.5 and 10.6 but is problematic in 10.7.