- should I build a local user and a ldap user?
There is no need to build a local user account. It is a good idea to keep service accounts local (such as root, operator, oracle, etc.), however to have group membership in the domain, you will need a matched domain account.
If you want the account to use local credentials instead of domain creds, you will need to use the libpam_updbe module in your pam.conf which will enable the user of pam_user.conf, which will allow you to have exclusions on a per user basis.
You could use a trick, whereby you mimic the AD group set locally to allow local accounts to exist in domain groups, but this is a bit of a pain. It's technically central management (or single sign-on) by replication, not by directory service.
- what about uid, should they be different users?
Unless your intent is for users to have multiple accounts on the same host with different authentication sources, then, no, use exactly the same.
- if so, should they share the same home directory?
If they don't use the same UID, you won't be able to share the same home dir without a messy group system.
- I tried to change a password on unix for an Active Directory user, but I got and error in the syslog file saying "Required parameters in kdc.conf missing while initialising kadmin"
Here is a working krb5.conf:
[libdefaults]
default_realm = MYDOMAIN.CA
default_tgs_enctypes = DES-CBC-CRC
default_tkt_enctypes = DES-CBC-CRC
ccache_type = 2
checksum_type = 1
[realms]
MYDOMAIN.CA = {
kdc = dc1.mydomain.ca
kdc = dc2.mydomain.ca
admin_server = dc1.mydomain.ca
kpasswd_server = dc1.mydomain.ca
}
[domain_realm]
.mydomain.ca = MYDOMAIN.CA
[logging]
kdc = FILE:/var/adm/syslog/krb5kdc.log
admin_server = FILE:/var/adm/syslog/kadmin.log
default = FILE:/var/adm/syslog/krb5lib.log
[appdefaults]
telnet = {
forward = true
forwardable = false
autologin = true
fallback = true
}
rlogin = {
forward = true
forwardable = false
fallback = true
}
remsh = {
forward = true
forwardable = false
fallback = true
}
kinit = {
forwardable = true
proxiable = true
tkt_lifetime = 10h
renew_lifetime = 5d
}
ftp = {
fallback = true
}
Noting that in my environment, every host has an AD host and ftp service account (user accounts) that has an exported key, that has been imported on the host. Example:
myhost2 # klist -k
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
7 host/myhost2.aecl.ca@MYDOMAIN.CA
7 ftp/myhost2.aecl.ca@MYDOMAIN.CA
- should I build the home dir manually
There's no reason you can't script it, but adding a user with AD Users and Computers will not work like useradd.
- do you have best practice guide that I should follow?
The best practices guide would be the same as the one noted above regarding the integration of LDAP-UX and AD. That said, it will not go into specifics around your environment, details on limiting users's access to specific hosts (authorisation, by pam_authz), how the automounter functions integrate (or not), etc.
- I have a service bureau machine, where few customers run our application from, should I built a forest for each client or share the same forest?
LDAP-UX (unless something has changed and I don't know yet) does not support multiple forests. So, unless you have a bureau machine for each client, a forest for each would not work very well.
From a security perspective, if you have multiple clients logging into the same system, and you trust them enough to do so (NDA, background checks, etc.) I wouldn't worry about it too much. If you don't have trust, why are you letting clients log directly into the any system, never mind the same system?
- What about security?
A few points:
Limit lgoin access to hosts using PAM_authz (/etc/opt/ldapux/pam_authz.policy) - use group membership in an AD group to allow or deny, this will also allow for easy reporting.
For group membership in the AD, add the user to their primary group as an additional, for better reporting (or you won't be able to look at the group and see the members in AD).
Use SSL, set up your CA etc. Do NOT install IIS on your CA server. Yes this is counter to other statements. It means that adding your cert to the host will require export from the CA as a x509 cert file and import using certutil on the hosts, by hand.
Your self-signed cert will expire after 2 years. When this happens, all of your hosts will stop connecting properly. Set a schedule in advance to renew, then export (at CA) and import (at hosts) the new cert.
Set your windows password policy to use no shorter than 15 character passwords. (Removes the LM-hashing issue of taking a 14char passord, split into two 7 chars, then DES encrypt each section, very easy to crack).
Ensure that any local service account UIDs are in the disable_uid_range entry in your ldapux_client.conf
Use a couple of different ldapuxprofile entries in the AD to allow you to select a couple of different primary LDAP servers to allow for load balancing.
Do not host your DNS with your KDC, LDAP, SSL servers on the same hosts. If your DNS server is down, and it's also your primary KDC/LDAP/DC server, logins could take up to 10 minutes to complete. This is due to TCP timeout limitations.
Do some testing around failure of KDC, DNS and other components so that you understand the impacts.
Change the permits on the utilities under /opt/ldapux to limit non-root access. In particular ./bin/*, ./config/* ./contrib/bin/*, ./migrate/*
Enable shadow passwords. In the /etc/opt/ldapux/ldapux_client.conf, set password_as="x".
Ensure that the newest version of ssh is installed and disable root logins (use a service account or domain account, then su to root, or better yet, use sudo). Disable v1 (protocol 2 in /etc/opt/sshd/sshd_config).
Use SHA512 for hashing non-root passwords ont he local host. You need to install PHI (Password Hashing Inftrastucture), then in /etc/default/security, set:
CRYPT_DEFAULT=6
CRYPT_ALGORITHMS_DEPRECATE=__unix__
Crypt will continue to work, but new passwd changes will go to SHA.
Set your syslog to log to an alternate host.
Use the CIS benchmarks to check against your host (
www.cisecurity.org). There are HP-UX, LDAP, Windows, and many other benchmarks and scoring tools for assessing your environment. They are all consensus based by industry experts. This is an EXCELLECT resource.
You can also use Bastille, which is a great little tool, especially for learning, but you need to understand what it is doing, which I why I like to do it myself.
Best regards,
Don
