LDAP, RADIUS, Diameter, FreeIPA, Free Beer?

These are not exactly right, but think of them more or less this way :)
  • LDAP is more the format to user user data. So, a DB, and command/tools to query and manipulate the database. Can be used as simple replacement to NIS for unix login and ssh.
  • RADIUS is a protocol that provies all the 3A's: authentication, authorization, and accounting. LDAP , without extension, does not provide accounting, or support for One Time Password (OTP/MFA).
  • Diameter, it is the wacky world of unix, such a thing exist. Google for it :D
  • FreeIPA: Integrated system that provides Directory Server (LDAP), MIT Kerberos, NTP, DNS, Dogtag Certificate System.


  • See Also:
  • Linux.html#authconfig
  • LDAP

    LDAP is a user database, and it does in Unix what MS Active Directory does in Windows. From Operating System Admin perspective, LDAP would typically be used to replace NIS (or NIS+ or scattered local passwd files). If you are pondering if you should migrate to LDAP, you'll wish the answer was 'NO' :) [cuz of the headache, but it is much better in term of security]
    LDAP is much more complex than NIS, and OS support wasn't rock solid as in NIS back in 2006, but it is used everywhere now. Automount maps retrieval from LDAP is quite complex and not well supported. Older OS LDAP support is rather spotty, and forget about OS that have been EOL-ed by the vendor!
    LDAP itself is not too bad, but configuring system to use it, especially with automount maps, radius, kerberos, etc can get convoluted quickly :) This cheatsheet doesn't covere everything, maybe not even 10% of it. but hopefully there is some useful info for you.

    LDAP Tree Conceptualization

    While LDAP is a user "database" repository, do not think of it as a Relational Database. It has no resemblance to RDBMS. The only thing that bear resemblance from RDBMS is the "key" and maybe "attributes", other than that, forget everything you learned about Relational DB when working with LDAP. Definately forget about those Boyce-Codd Normal Form!!
    File Cabinet Numbering
    TBD...
    Special File System Tree
    TBD...

    LDAP User Management

    To disable/lock out a user, one can add the attribute to the user dn: nsAccountLock: true. The GUI console provide a way to click "disable" under the Accounting tab. However, OS support for this flag is spotty. For example, RHEL 3 does, but Solaris 8 does not. Thus, the admin should change the user default shell to something like /bin/false.

    The Unix sys admin tradition is to also change the user's password to some random text to prevent the user from logging in. Sure, theoretically, there is a chance the password could still be guessed, but this isn't likely in practice, and may involve non-print characters. Finally, note that if POSIX account is completely disabled, it would delete the UID info, which are typically undesirable due to the need to keep UID/GID for historical reference (files ownership, etc).

    LDAP Profile Management

    Some OS need a profile to be stored on the LDAP server so that client side LDAP config can be updated in a single server location, rather than updating on each machine. In practice, profile may add too much complexity for too little gain.

    Sun also claims profile add security, preventing user from joining a machine to LDAP w/o the LDAP admin knowledge. However, if the user have root in one client, files in /var/ldap can be copied from one machine to another. The encrypted password is copied, obliviating the need to know any password to bind to the Directory. Lastly, most site allows anonymous bind just as ypcat passwd is not secured anyway. At the end of the day, the sys admin don't have a choice whether to use profiles or not. Solaris and HPUX use profiles, and AIX and linux don't.

    Some admins like to create one profile for each version of a given OS, so that vendor gratuitous changes in new version won't affect other versions. This come at a cost of maintaining more profiles. Pick your own poison :) On the other hand, if there are multiple sites, then site-specific profile would typically make sense.

    If there is only one domain, storing profiles near the root would be good. eg OU=profiles,dc=unixville,dc=com. But even if there are multiple domains, it maybe best to put them in the same location anyway, using different name for profiles beloging to different domain/site. This is mostly to ensure client bind process can locate the profile easily and no guess work as to which part of the tree the profile came from.

    Solaris
    So far, Solaris 8 thru 10 can use the same profile without any noticeable problem. It seem easiest to create the profile from a Solaris 9 client and bind using Directory Manager to seed this process.
    HPUX
    Each version of HP-UX add a bit more "feature" into the ldapux-profile. 11.00 has a basic profile, 11.11 added something, yet 11.23 bloated it up even more. The nature of ldap client is that they ignore directives they don't understand. As such, it worked pretty well to seed the initial profile using an 11.23 client, binding as Directory Manager to upload the profile directly to the LDAP server. Once done, the client can be reconfigured to bind as proxy agent.

    Lastly, I would like to mention that it is possible for LDAP-UX to use the Solaris profile, at least for HP 11.11. However, latest versions of the two OSes seem to diverge and maintaining separate profiles may reduce compatibility problems down the road.

    LDAP Gotchas

    Smart Referals
    Probably want to stay away from them from NIS migration perspective. Linux is probably the only platform that supports it. AIX will traverse them and loop thru the many servers set by the smart referals and cause huge delays in telnet session connection, automount maps retrieval, and make machine extremely sluggish.
    Solaris, it is a bit better. It still crosses the smart referal servers more often than needed, resulting in delayed performance. Even when profile is set that it should not follow the smart referals, it doesn't honor it. Performance is acceptable if smart referals is a must. But even then, I don't see automount maps referals to function correctly.
    HP-UX. Don't know if it cause problem yet, but it doesn't provide the correct function of retrieving data from the smart referal automount maps.

    RSH vs REXEC
    [This was back in 2006]
    The protocol definition for RSH vs REXEC and other similar command:
    (a) rsh use the Berkeley rcmd(3) library, and requires the binary to be setuid root so that it run in priviledged ports and scan for .rhosts in remote server.
    (b) rexec use the rexec(3) library. It does not scan .rhosts so no need to run as root. Instead, it provide user password in clear text to remote server to login. remsh is the same as rsh, just renamed to avoid clash with the "restricted shell"
    (c) rlogin is for remote console login. It handles less control character than TELNET. Most system implements "rsh host" w/o a command as a call to rlogin for interactive login. RSH is left for executing command on remote host and streaming the output back to the source machine. RLOGIN also uses the Berkeley rcmd(3) library.
    (d) rcp is remote copy akin to rsh wrapped around files directly.
    (e) ssh default behaviour is to emulate rsh with command. For interactive login, it probably follows the rlogin algorithm, but hangles control characters much better, akin to telnet. Further, ssh is smart enough not to read user login/password from a std out redirect, but must ask on an interactive keyboard (expect can emulate keyboard login).

    Note that
    (1) RSH/RLOGIN/SSH scan user db differently than
    (2) TELNET/REXEC
    At least in AIX, the former set seems to invariably look for local /etc/passwd user first, whilst the latter look at LDAP. nsswitch.conf on other system may have effect on this, but Solaris 8 RSH is looking at local passwd first for sure. Further note that AIX 5.3 "rsh hostname cmd" behaves more like (2). It is a bizare world of intricate details and buggy implementations a/o protocol :-/ Note that aix man page on rexec says it only look at COMPAT but in fact it look at LDAP first!

    AIX has a variable AUTHSTATE that get set to:
  • compat when login using rsh
  • LDAP when login using telnet
  • files can be set manually to force UID to username resolution thru files first (still go thru other method if it fails to find it in files).
    It seems safe to set this variable in /etc/profiles and /etc/csh.cshrc to "compat" and all seems to work well, sourcing local files first.

    RSH issues
    RSH is likely to work in LDAP environment. However, getting RSH to allow user to login without prompting for password (use of the insecure .rhosts, etc) is likely to be more problematic. Solaris may need patches and config on pam.conf. HP-UX will need update on pam.conf, and perhaps a myriad of other config depending on security model. Refer to HP PAM doc.

    SSH issues
  • If you compiled OpenSSH from source, you will need to include PAM support.
  • If you got openssh package from SunFreeware.com, the older version won't work with LDAP.
  • If you are using vendor provided SSH, and vendor supplied LDAP libraries, then all should be good. If on the other hand third party LDAP libraries are added, eg from PADL.com, then things may break.
    Automount issues
    The typical sys admin would put lot of automount maps on NIS, and just about every unix OS automount can retrieve these maps from NIS. However, such assumption would be very wrong when migrating to LDAP. While the LDAP server can store anything one throws at it, the data may not always be retrievable :( There is an rfc defining how to store automount maps in LDAP, and when configured correctly, will work. But it need substantial client-side support. Autofs on just about every OS client need to be updated. Solaris 9 and older need patches. AIX 5.2 and older don't have upgrades available. HP-UX 11i can use the Enhanced-AutoFS package, but it need lot of OS patches and kernel recompilation to support it. Newer Linux can run up2date to patch the autofs rpm. See the client section below for more details. In general, treat each version of each OS as an independent entry in the configuration matrix, and test everything to ensure your config works!

    LDAP command

    ldapsearch

    Query ldap directory server info, output in LDIF format.
    Sample ldap search commands...
    solaris 10 argument structure:
    ldapsearch -b SearchBase [options] FILTER [attributes]
    	[options]
    	-h ldaphost	# ldap server to connect to, default to localhost
    	-D bindDN	# user used to connect to LDAP, default to anonymous
    	-d n		# debug level, bits flags. 
    	-e 		# minimizes base-64 encoding (like tab!)
    	-T		# don't fold/wrap lines.  ldiff treat lines starting with space as
    			# continuation of previous line, def width is 80 chars.
    	-p 1234		# use port 1234 (default ldap use 389, TLS is 636)
    	-L		# ...
    	[attributes]
    	select the addributes to list.  Default to all, but can limit to display only a certain ones, eg:
    	dn 		# list only the dn entry
    	dn cn		# list both dn and cn entries, nothing else.
    
    
    
    <!-- -->
    
    ldapsearch -b "dc=unixville,dc=com" -h ldapsvr        uidNumber=5001
    ldapsearch -b "dc=unixville,dc=com" -h ldapsvr -p 389 gidNumber=5001
    	# find entry with a given uid or gid number.
    ldapsearch -b "dc=unixville,dc=com" -h ldapsvr memberUid=tin dn
    	# find all gruops whereby tin is a member of (unix secondary group membership)
    	# display only the dn (name of group and "domain" group is defined in)
    ldapsearch -b "l=sf,l=us,dc=unixville,dc=com" -h ldapsvr uid=* dn
    	# list all user in a the "domain" l=sf,l=us
    ldapsearch -b ou=Groups,ou=sc,ou=ca,ou=na,dc=hybridauto,dc=com -h ldap007 cn=* dn
    	# list all group names of a given domain.
    
    
    ldapsearch -b "dc=unixville,dc=com" -h ldapsvr "uid=tin*" dn cn uidNumber
    	# find all username starting with tin, display only the fields dn, cn, uidNumber.
    ldapsearch -b "ou=us,dc=unixville,dc=com" -h ldapsvr "givenName=*tin*" dn givenName uidNumber
    	# find all user real name containing tin anywhere, case insensitive
    ldapsearch -b "ou=us,dc=unixville,dc=com" -h ldapsvr -D "cn=Directory Manager" "givenName=tin" userPassword
    	# -D = perform search using specific user credentials
    	# Certain attributes such as shadow password can only be retrieved by
    	# priviledged user.
    	# Finally, some info is only available on the Directory Server (eg via
    	# export) but not as ldapsearch at all.  eg attributes for Person entry: 
    	# creatorsName, modifiersName, modifyTimestamp, nsUniqueId
    
    
    ldapsearch -b "cn=config" -h ldapsvr -D "cn=Directory Manager" "objectClass=*"
    	# retrieve config info, objectClass=* serve as wildcart for "all"
    ldapsearch -b "cn=config" -h ldapsvr -D "cn=Directory Manager" "objectClass=*" | grep  passwordStorageScheme
    	# grep for the password encryption scheme (crypt, ssha, etc).  
    	# aix 5.3 only supports crypt
    	# solaris and linux support both crypt, ssha.
    
    ldapsearch  -b "cn=schema" -h ldapsvr -D "cn=Directory Manager" "objectClass=*" 
    	# retrieve all info on the schema of the directory tree
    
    ldapsearch -h ldapsvr  -b "o=NetscapeRoot" -D "cn=directory manager" "objectClass=*" 
    	# retrieve fedora directory server internal config info
    	# NetscapeRoot cuz fedora/redhat ds is based off the old netscape directory server 
    
    ldapsearch -h ldapsvr -L -b automountMapName=auto_master,l=sf,l=ca,c=us,dc=element50,dc=com objectclass=*
    	# something similar to "ypcat auto.master"
    
    ldapsearch -h ldapsvr -T -b automountMapName=auto_home,ou=us,dc=unixville,dc=com  objectClass=*  dn                   | grep -v ^$ 
    ldapsearch -h ldapsvr -T -b "ou=us,dc=unixville,dc=com"                          automountkey=*  automountInformation | grep home
    	# list automount maps entries for auto_home, similar to "ypcat auto.home"
    
    ldapsearch -h ldapsvr -T -b automountMapName=auto_home,ou=us,dc=unixville,dc=com  automountKey=tin
    	# retrieve automount info about /home/tin
    
    ldapsearch -h ldapsvr -T -b dc=unixville,dc=com  automountkey=/home
    	# find out where /home is refered and how it is defined (auto.master, auto_master, which domain/ou)
    
    ldapsearch -h ldapsvr -b dc=unixville,dc=com nisnetgrouptriple=*lungfish* | less
    	# find out which netgroup a machine called lungfish belongs to, long output!
    
    

    AIX
    ldapsearch is located in /usr/ldap/bin. Parameters are similar to Solaris.
    Linux native
    Parameters used by /usr/bin/ldapsearch from the opendap-client rpm, most of them are similar to the Solaris ldapsearch:
    ldapsearch [options] FILTER [attributes]
    	[options]
    	-x 		# no SASL (option not in Solaris)
    	-LL		# suppress comments in output
     	-b SearchBase	# specify the starting point where search will begin.  Typically root.
    	-h ldaphost	# ldap server to connect to, scan /etc/ldap.conf if configured.
    	-D bindDN	# user used to connect to LDAP, default to anonymous
    	-d n		# debug level, bits flags. 
    
               [------------- options -------------]   [-- FILTER (req) --] [attr]
    ldapsearch -b dc=hybridauto,dc=com -h ldap007 -x   nsds5ReplConflict=*    dn    | grep -v ^$
    	# find all entries with replication conflict problem, 
    	# where dn is has nsuniqueid appended to it.  eg:
    	# nsuniqueid=f0b6791e-1dd111b2-80dba88a-997d0000+uid=duptest,ou=people,dc=hybridauto,dc=com
    	
    

    FEDORA-DS
    Parameters used by /opt/fedora-ds/shared/bin/ldapsearch installed by the RedHat/Fedora DS:
    Some strange Linux machines default ldapsearch
    Probaly old school linux machines...

    ldapsearch -x -ZZ -s "dc=unixville,dc=com" -b ""
    	-x 	= no SASL
    	-ZZ	= use TLS
    	-s 	= search base
    
    
    

    ldapadd

    ldapadd will add info to the directory server, erroring out if the entry already exist (as defined by the dn). Must be done when the Directory Server is running, live. (ldif2db will overwrite, see below).
    FEDORA-DS
    ldapadd -x -W -c -D "cn=Directory Manager" -h ldapsvr -f data.ldif
    	ldapadd is really "ldapmodify -a", so it share the same options, see below
    
    
    Sample data.ldif file used to add a user, a group and simple automountmap entry for the home directory.
    
    #
    # add a user 
    #
    dn: uid=tin,ou=People,l=sf,c=us,dc=unixville,dc=com
    uid: tin
    cn: Tin Ho
    givenName: Tin
    sn: Ho
    mail: tho01@yahoo.com
    objectClass: person
    objectClass: organizationalPerson
    objectClass: inetOrgPerson
    objectClass: posixAccount
    objectClass: top
    userPassword: {crypt}solarisShadowOk
    loginShell: /bin/bash
    uidNumber: 168
    gidNumber: 168
    homeDirectory: /nfshome/tin
    gecos: optional NIS gecos field 
    
    #
    # eg for adding a group
    #
    dn: cn=sn-group,ou=Groups,l=sf,c=us,dc=unixville,dc=com
    objectClass: posixGroup
    objectClass: top
    cn: sn-group
    gidNumber: 168
    memberUid: moazam
    memberUid: rlee
    memberUid: lys
    
    #
    # eg for automount entry (automount object need to be already defined prior to this add)
    # this form is acceptable by Solaris and new Linux autofs (ditto for Aix and Hpox, 
    # but the old linux autofs will not understand it, so get rpm 4.1.3-174 or newer)
    #
    dn: automountKey=tin,automountMapName=auto_nfshome,l=sf,c=us,dc=unixville,dc=com
    objectClass: automount
    automountKey: tin
    cn: tin
    automountInformation: -rw casper:/export/home/&
    
    When first setting up LDAP repository, initial maps for auto.master, auto.nfshome, etc need to be defined. It maybe easier to do this using the GUI, see below. The LDIF files defined here can be used for addition or verification in subsequent ldapsearch. Pay special attention to dot(.) vs underscore(_) below.
    
    #
    # auto.master direct map (Linux) 
    # 
    dn: automountMapName=auto.master,ou=sc,ou=ca,ou=na,dc=hybridauto,dc=com
    objectClass: top
    objectClass: automountMap
    automountMapName: auto.master
    
    dn: automountKey=/nfshome,automountMapName=auto.master,ou=sc,ou=ca,ou=na,dc=hybridauto,dc=com
    objectClass: automount
    automountKey: /nfshome
    cn: /nfshome
    automountInformation: ldap:automountMapName=auto_nfshome,ou=sc,ou=ca,ou=na,dc=hybridauto,dc=com
    
    dn: automountKey=/net,automountMapName=auto.master,ou=sc,ou=ca,ou=na,dc=hybridauto,dc=com
    objectClass: automount
    automountKey: /net
    cn: /net
    automountInformation: -hosts
    
    
    #
    # auto_master direct map (Solaris?)
    #
    dn: automountMapName=auto_master,ou=sc,ou=ca,ou=na,dc=hybridauto,dc=com
    objectClass: top
    objectClass: automountMap
    
    dn: automountKey=/nfshome,automountMapName=auto_master,ou=sc,ou=ca,ou=na,dc=hybridauto,dc=com
    objectClass: automount
    automountKey: /nfshome
    automountInformation: auto_nfshome -rw,hard,intr,vers=3,rsize=32786,wsize=32786
    
    dn: automountKey=/net,automountMapName=auto_master,ou=sc,ou=ca,ou=na,dc=hybridauto,dc=com
    objectClass: automount
    automountKey: /net
    automountInformation: -hosts
    
    #
    # auto_nfshome
    #
    dn: automountMapName=auto_nfshome,ou=sc,ou=ca,ou=na,dc=hybridauto,dc=com
    objectClass: top
    objectClass: automountMap
    
    
    

    ldapmodify

    Change existing data already stored in the Directory Server
    Solaris
    
    ldapmodify -D uid=tinh,ou=people,dc=geneusa,dc=com -h ldapsvr -p 1389 -f ./data.ldif
    
    
    FEDORA-DS
    ldapmodify -x -W -c -D "cn=Directory Manager" -h ldapsvr -f data.ldif
    	-h specify the server to connect to to perform the add
    	-f FILENAME, if using path with filename, must use /full/path/to/file
    	   If no filename is defined, ldapmodify expect all commands to come from std in, one line at a time;
    	   empty line by itself to indicate end of record.
    	-x = simple auth instead of SASL
    	-W = prompt for password on the CLI
    	-c = continuos operation, instead of exiting when errors happens
    	-D USER = the user to perform the change as
    
    	-v = verbose
    	-n = dry run, don't acutally do anything
    
    
    #
    # modify user account try adding the objectClass=shadowAccount
    # so that user can login to Solaris 8 and related machines
    # Note that some ldapmodify binary may crook on comments!!
    # (Solaris and many Linux can't parse #)
    # Blank lines are potential problems, so avoid them :)
    #
    dn: uid=tin,ou=People,l=sf,c=us,dc=unixville,dc=com
    changetype: modify
    add: objectClass
    objectClass: shadowAccount
    
    
    #
    # Add a password field to user whose account have empty password
    # ie, no userPassword clause definated at all
    #
    dn: uid=mlee,ou=People,ou=sc,ou=ca,ou=na,dc=hybridauto,dc=com
    changetype: modify
    add: userPassword
    userPassword: {crypt}*notSet*
    
    
    
    #
    # Change user password field to indicate that it is in locked state.
    #
    dn: uid=tho,ou=People,ou=sc,ou=ca,ou=na,dc=hybridauto,dc=com
    changetype: modify
    replace: userPassword
    userPassword: {crypt}*AccountLocked-2006-07-26*
     
    #
    # Change account to lock state, not all OS honor this.
    #
    dn: uid=tho,ou=People,ou=sc,ou=ca,ou=na,dc=hybridauto,dc=com
    changetype: modify
    add: nsAccountLock
    nsAccountLock: true
    
    
    
    
    #
    # Change a group definition: add a user to its membership list
    #
    dn: cn=sysadmin,ou=Groups,ou=sc,ou=ca,ou=na,dc=hypbridauto,dc=com
    changetype: modify
    add: memberUid
    memberUid: tho
    memberUid: mlee
    

    Import/Export

    db2ldif

    /opt/redhat-ds/slapd-ldapsvr/db2ldif -s dc=unixville,dc=com -a export.ldif
    Export all site data for the domain uxville.com, place it in LDIF format. This file can then be edited, eg sed 's/\t/ /g' to remove all tabs, and then reimported.
    For the -a option, output file may need to have full path specified, and output location may need to be writable by user "nobody". If option -a is not used, the output will be stored automatically in a location where "nobody" can write to, typically /opt/redhat-ds/slapd-ldapsvr/ldif.

    /opt/redhat-ds/slapd-ldapsvr/db2ldif -n userRoot
    Brief test, output info related to "default master db" that stores root-level data, such as profiles, etc. It does not output data in sub-suffix databases related db that stores user data. so it is usually small.

    ldif2db

    /opt/redhat-ds/slapd-ldapsvr/ldif2db -s "ou=us,dc=unixville,dc=com" -i /full/path/to/import.ldif
    Import data in ldiff format. Typically req to be importing a specific section of the domain. It will overwrite data that already exist under the subtree of the import. The import has to be done when the directory server is turned off. If using replication with multiple servers, the other machines need to be re-init from this master server that did the import.

    LDIF

    LDIF is the standard data exchange format. It is a simple ASCII file with special text formatting. Each entry has a dn. Different entries are separated by blank lines. line that begin with a space is considered to be continuation of previous line, which are typically wrapped at 80 chars. Anything not presentable in standard ASCII will be uuencoded in base64.
    Besides LDIF, there is also format based on the XML standard called ____. It seems to be seldom used.
    < !--
    Additional example of ldif file for various objects can be found at: http://docs.sun.com/app/docs/doc/816-4556/6maort2ro?a=view

    FEDORA-DS

    Fedora Directory Server is the open source version of RedHat Directory Server.
    The RH DS came from the Netscape Directory Server (6.1). The Netscape DS was also developed by Sun and branded as iPlanet DS and later Sun ONE DS. HP also repackage the Netscape/Red Hat DSwith their LDAP-UX. Thus, these products are largely the same.

    GUI Console

    Fedora DS has a Graphical Console. There is two piece to it, an app/web server that typically configured to listen on port 5555, which can be started as:
    cd /opt/fedora-ds
    ./start-admin
    And a client part. A web browser can point to http://ldapsvr:5555/ and get lightweight ldap server queries, or use the full featured java client which get started as: cd /opt/fedora-ds
    ./startconsole
    The GUI console can be used to perform admin task on the Directory Server configuration or for modifying data in the LDAP data tree. Below are several examples of adding objects in the "database" tab.

    Add Unix User

    Right click on the People OU, click new, user. For Unix user, check on the Posix Account entry. Furthermore, go to advance attributes and add the "shadowAccount" attribute.

    Add Unix Group

    Right click on the Groups OU, click new, other object, posix group.

    Add Automount Map

    automount map is for defining an entirely new set of automount entries, such as /import, /products, etc.
    Here is an example for defining automount maps in LDAP for the first time, adding a auto.master, auto_master and finally a sample indirect map for /nfshome . Pay special attention to dot(.) vs underscore(_) below.

      Defining auto.master (master map used by Linux, AIX and HP-UX?)
    1. Right click on the desired OU where the automount map should be added (eg, ou=sc,ou=ca,ou=na,dc=hybridauto,dc=com)
    2. Click new, other object, automountMap
    3. Enter "auto.master" in the automountMapName field.
    4. Then, inside this newly created auto.master object, right click, new, other object, automount
    5. In the automountInformation field, enter info like "ldap:automountMapName=auto_nfshome,ou=sc,ou=ca,ou=na,dc=hybridauto,dc=com"
    6. In the automountkey field, enter "/nfshome"

      Defining auto_master (master map used by Solaris?)
    7. Right click on the desired OU, as in step 1 above
    8. Click new, other object, automountMap
    9. Enter "auto_master" in the automountMapName field.
    10. Then, inside this newly created auto_master object, right click, new, other object, automount
    11. In the automountInformation field, enter info like "auto_nfshome"
    12. In the automountkey field, enter "/nfshome"

      Defining auto_nfshome (indirect map used by all systems)
    13. Right click on the desired OU, as in step 1 above
    14. Click new, other object, automountMap
    15. Enter "auto_nfshome" in the automountMapName field.
    16. Entries in auto_nfshome will be added in the section below "Add Automount Entry".
    The info can be verified by using ldapsearch and compare it against the ldif used in the ldapadd section above.

    Add Automount Entry

    Sample automount entries would be the various user's home dir that are defined under /home. Thus, /nfshome/tin with content of nfssvr:/export/home/tin would be one automount entry.
    For user home directory that need atuomount entry to define which server to use for the actual mount, To add a new entry:
    1. right click on the desired automount map (eg auto_nfshome)
    2. click new, other object, automount.
    3. Enter the mount key into the automountKey field
    4. Enter mount path info and mount option into the automountInformation field

    Change Default Posix (Unix) Password Encryption

    When creating unix user account using the GUI console, the password strings need to be encrypted in the same method that client OS expectes them to. While newer OS can support MD5 or SSHA, CRYPT is still the universal standard. Thus, it is best to set the console to encrypt user password using CRYPT by default. Solaris NIS use CRYPT by default.

    Method 1 - What Red Hat consultant told me and I know it works:
    1. Go to the Directory tab
    2. Click on the config node in the tree, right click, select advance properties (in a nutshell, we are editing the properties for the node cn=config.
    3. Scroll to the bottom where the attribute "passwordStorageScheme" is listed. By default, it says SSHA. Change it to say "CRYPT"
    Method 2 - What is described by the Admin Guide:
    1. Go to Config tab,
    2. Data node in the LDAP tree.
    3. On right side, go to Password tab. Toward the bottom, it has option to choose password encryption policy. The default is SSHA, change it to CRYPT.

    To verify that default password is created using CRYPT, perform a password change on a test user, then perform ldapsearch on this user using the cn=Directory Manager credentials. Encryption method is prefixed as {CRYPT} or {SSHA}.

    Backing up DB

    /opt/fedora-ds/slapd-SVR/db2bak		# run the backup
    /opt/fedora-ds/slapd-SVR/bak/DATE/	# dir where the files are stored (mostly Berkeley DB files)
    

    Index

    Some fields are not indexed by default, and when used as a NIS replacement, having these indexes would greatly improve performance.
    To create indexes,
    1. Go to config tab
    2. Click on "data" on the ldap tree
    3. Expand to the desired database container config, indexes tab should appear on right
    4. Click on attribute, and select the attribute that should be added to the index.
    5. Typically, equality is the box that need to be checked for indexing to be performed on.
    The above steps need to be done on each LDAP server, on each database repository (eg when different domains/OU use different database backend).

    Replication Conflicts

    Records from replications with conflicts are marked by nsds5ReplConflict. If the conflicts are specific to a single domain (and espcially in a dedicated consumer), the easiest way to remove them is to "Initialize the Consumer" from the Replication Config.

    Otherwise, refers to http://www.redhat.com/docs/manuals/dir-server/ag/7.1/replicat.html#1106141

    Replication Agreement


    Example of setting up a new server for a new domain, and adding replication.
    Step# Central Master Server (eg ldap1) Local Replica (new server, eg ldap3)
    I. Setup Directory Server Admin metadata
    0   Run ./setup to configure the directory server.
    Enable "Change Log", db dir = /opt/redhat-ds/slapd-ldap*/changelogdb/ (owned by nobody:nobody, chmod 755)
    restart slapd
    1   Create user "uid=replication manager" under "cn=config" (in Directory tab)
    2   Remove unecessary data from the directory tree (eg: People, Group, Special users)
    3   For replication, userRoot, ensure to
  • check "Enable Replica"
  • uid=replication manager,cn=config
  • dedicated consumer
  • 4

    Replicate "userRoot" data to the new server

    This will setup the root dc=hybridauto,dc=com to the new remote server.

     
    II. Replicate existing domain/database to new server
    5   In config tab, create databases matching all desired subsuffices for the data/domain that wish to be made available in this new server
    6   Check to ensure all subsuffix for db defined above exist, they should have been replicated from Part I.
    7   Enable replication (on Local Replica, this would typically be dedicated consumer, so read-only).
    8 Add replication agreement for each database/domain defined in step 5.  
    III. Setting up new domain, getting data to new server
    9 In config tab, create new subsuffix with db for it. eg, create ou=seattle,ou=on,ou=na,dc=hybridauto,dc=com  
    10 In database tab, create a matching subsuffix  
    11 Enable replication. (On Central Master Server and Backup Master Server, this would need to be a "multi-master" replicatoin)  
    12   In config tab, create subsuffix matching that created in step 9, create the db with it to store the data locally
    13   In database tab, create ou matching above (may not really need to create this manually)
    14   Assign a unique replication id to this machine to use (if servers are numbered sequentially, this is a good number to use).
    15   Enable replication (It maybe desirable to setup the Local Replica to act as Local Master for this domain that host local user, as such, the replication would be a "multi-master", and not dedicated consumer.
    IV. Setup Replication agreement
    16 In config tab, replicatin branch in the tree:
  • centralServer-seattle, new agreement: SE-central2se
  • consumer is ldap3:389
  • simple auth, uid=replication manager, cn=config (created in step 1, enabled for writing in step 3)
  • Do NOT initialize consumer (at this time).
  •  
    17   In config tab, replication branch of the tree, create a "back-fill" replication from the local master back to central master, db name: localMaster-seattle:
  • right click and add a new replication agreement.
  • call it SE-SE2central
  • consumer: ldap1:389 (central master server)
  • Do NOT initialize conumer
  • 18

    Tail the error log (slapd-ldap1/logs/error).
    Initialize consumer.

     
    V. Replication with Backup Master - repleat stage IV, adjust as:
    19 (step 16): name replication agreement as SE-backup2se, multi-master replication  
    20   (step 17) name for replication:
  • localMaster-SE
  • SE-SE2backup

  • When defining the replication agreements, for database that need multi-master, it maybe best to select such type of replication from the beginning. This is because the GUI console is rather buggy, and it has a tendency to put in a random number if the replication is first setup as dedicated consumer. If error happens, it is probaby best to blow away the replication agreement and redo it. For those really brave, the slapd server can be shut down and edit the dse.ldif file manually :) It was actually possible to define the replication agreement as ldif file that one just paste into the dse.ldif, but I don't konw the details.

    Other things to remember when setting up additional server:
  • Copy custom schemas into the schema directory and restart the DS. /opt/redhat-ds/slapd-*/config/schema, typically starts with number 61 thru 98.
  • Uniqueness plugin, either thru ldif import or set them up manually on the GUI console.
  • Tail the error logs when doing replicaiton test. Sometime console reports status as good but when in fact error log shows replication problems.
  • Ensure each server is assigned a uniq replicaiton id. Last octet(s) of the server IP address may work. Naming the servers with numerical sequence and using that number may also be a good idea.
  • Perform any server-specific changes to each machine, eg change password encryption from default SSHA to the more compatible CRYPT.

    Server Transfer


    If there is ever a need to migrate the RedHat Directory Server from one physical server to another, here is one possible method. This method assumes that you have at least one other server that can pick up all the workload, or downtime is acceptable.
    1. Stop slapd
    2. Create a tar of the whole /opt/fedora-ds
    3. Transfer this tar to the new server
    4. Untar into /opt/fedora-ds (rename the existing dir if the fedora rpm has already been added)
    5. Shutdown or otherwise network disconnect the old ldap server
    6. Configure the new LDAP server to have hostname (and optionally IP) of the old server
    7. Start slapd on the new server

    LDAP Client Config and Troubleshooting

    Solaris

    Config files:
  • /etc/pam.conf
  • /etc/nsswitch.conf
  • 
    /etc/init.d/ldap.client stop		# restart ldap client bind process
    /etc/init.d/ldap.client start
    
    svcadm enable network/ldap/client	# solaris 10
    
    /usr/lib/ldap/ldap_cachemgr -g 		# generate a new cache, display status
    
    /etc/init.d/nscd stop			# restart name service daemon
    /etc/init.d/nscd start
    
    
    

    ldaplist

    Solaris support the ldaplist command that does the equivalent of ypcat in the NIS world. It is easier than ldapsearch in the sense that it will use the BASEDN and ldapserver that is already configured for a given ldap client machine. If ldaplist work, then the client is correctly configured to talk to the ldap server (whereas ldapsearch just means the ldap server is reachable). It is probably tuned to work with the Sun One Directory Server, but many specific queries will work with RedHat/Fedora DS also.
    Also, command works better when ldapclient init is used, rather than hacking the machine to work by copying files to /var/ldap.
    
    ldaplist    passwd "*"		# list all user, equiv of ypcat passwd
    ldaplist -l passwd tin		# display detailed info about user tin
    ldaplist -l group  \*		# list all groups and their members
    
    ldaplist    auto_master  \*	# list master automount info, like ypcat -k auto.master
    ldaplist -l auto_nfshome tin	# give specific details for /nfshome/tin
    
    ldaplist -l aliases root	# find out email alias definition for user root
    
    
    


    AIX

    AIX as LDAP client

    Config and Test Commands
    mksecldap -c -h ldap03.hybridauto.com -a "cn=Directory Manager" -p bigsecret -d "dc=hybridauto,dc=com" -u NONE
    ## Bind as Directory Manager, kinda bad.  
    ## Some older sys password is in clear text in teh ldap.cfg file!!
    
    mksecldap -c -h ldap03.hybridauto.com -a "cn=proxyagent,ou=profile,dc=hybridauto,dc=com" -p secret -A ldap_auth -d "dc=hybridauto,dc=com" -u NONE
    ## Works for AIX 5.3 with ML 3 patches, bind for authorization only, using
    ## proxyagent  (which is just a normal People OU in the profile OU).
    ## One can edit the ldap.cfg file and remove the user and password for
    ## anonymous bind.
    
    
    
    
    lsuser -R LDAP tin	# see if user "tin" is defined in LDAP
    			# AIX command, in /usr/sbin
    
    ls-secldapclntd		# check status of ldap connectivity, in /usr/sbin
    stop-secldapclntd
    start-secldapclntd
    restart-secldapclntd
    flush-secldapclntd
    
    
    Config Files
  • /etc/security/user
  • /etc/security/ldap/ldap.cfg
  • /etc/irs.conf
    1. Update needed if using PADL nss_ldap module.
    2. No changes needed in AIX 5.3, and there should be no clause for automount if it is to query LDAP for the maps (stating that it should query from LDAP makes it fail!)
  • /usr/lib/security/methods.cfg. LDAP clause need to be present, added by ldap.client.rte
  • /etc/pam.conf (no changes are typically required)
  • /etc/inittab has extra clause for ldap:
    ldapclntd:2:once: /usr/sbin/secldapclntd > /dev/console 2>&1
    Any service that depends on ldap user auth need to be placed below this line (eg Clear Case, custom rc script that start services using LDAP user credentials)
  • /etc/profile, /etc/csh.cshrc:
    $AUTHSTATE (env variable: LDAP, compat, files. It define default, first method for UID resolution)


  • /etc/security/user config details
    the "default" clause should say something like:
    default:
    	SYSTEM = "LDAP or compat or DCE"
    	(...)
    
    This would allow local user account to be checked. If the order is "compat or LDAP", ldap user who telnet in will see a small error message about "invalid login name or password" and then move on to LDAP and log the user right in (assuming currect pam.conf). If the order is "LDAP or compat", then somehow local user can still login even if there is matching USERNAME on LDAP with /bin/false for shell. IBM doc says DCE is used for X windows login, but seems to work w/o it anyway.
    Lastly, if somehow local user still doesn't work, then a specific clause for the user need to be added, one that looks similar to the entry for the root user. Either run commands like:
    chuser SYSTEM=compat db2inst8
    chuser SYSTEM=compat registry=files db2inst8
    (registry deal with where the password is stored. For LDAP, it would be "registry=LDAP"). Alternatively, one can edit the file manually. Final config should look like:
    db2inst8:
    	SYSTEM = "compat"
    	(...)
    


    IBM claims that the extension, RFC2307AIX, provides additional support for AIX 5.2 onward. It was supopsed to be a transparent addition that does not affect other clients that do not use such feature. The ldif file for schema update is provided on AIX machines at /etc/security/ldap/nisSchema.ldif . This extra support is not required, but provides AIX with additional user tracking support.

    Linux

    authconfig
    or
    /etc/ldap.conf
    /etc/nsswtich.conf
    
    anonymous bind works if server allows it, proxyagent bind wilL need to put password 
    in a separate file 600 root and contain password in clear text.
    
    
    automount: 
    /etc/sysconfig/autofs, define BASEDN so that it will locate the correct auto*master 
    autofs rpm version at least 4.1.3-174 need to be available to support maps retrieval thru LDAP.
    
    


    HPUX

    Config files:
    
    /etc/opt/ldapux/ldapclientd.conf	# LDAP-UX daemon config file
    /etc/nsswitch.conf
    /etc/pam.conf 		# can use pam.ldap as template
    
    Config commands:
    
    swlist -l product | grep -i ldapux
    # Ensure that ldapux package is installed.  
    # Need at least version B.03.30...
    
    cd /opt/ldapux/config
    ./setup
    # this is the main config for the ldap-ux module
    # to configure HP-UX to use ldap for user authentication
    # it is an interactive program
    # will ask ldap server name, port, and 
    # the hpux/ldapux profile dn path/location
    
    
    cd /opt/ldapux/config
    ./ldap_proxy_config -i
    cn=proxyagent,ou=profile,dc=unixville,dc=com
    proxyagentpass
    # configure ldapux to use a proxyagent
    # the two lines after the command are entered after the command is issued
    # there is no prompt, just enter "username" and password, 
    # one line at a time, and then the command prompt will return
    
    
    ./ldap_proxy_config -p
    # print out the config setup above
    
    ./ldap_proxy_config -v
    # verify proxy agent config, should return "verified - valid"
    
    Automount:
    
    swlist -l product | grep -i auto
    # Ensure Enhanced Autofs is installed
    # Need at least version ...
    
    
    
    


    Generic

    These are commands available in most OS, unless otherwise specified.
    
    id -a tin		# see id of user (all platform, but diff flags)
    
    getent  		# get entries from administrative database as def by nsswitch.conf
    	  		# avalable on solaris, linux, hp-ux.
            		# But there is NO service that look up automount maps :(
    getent passwd		# equiv of cat /etc/passwd, but retrieving the content from whatver nsswitch has configured .
    			# multiple source will be queried and result combined 
    
    getent shadow		# typically return blank.  encrypted pw not provided.
    
    getent passwd tin    	# see if user tin is recognized
    			# similar to ypcat passwd | grep tin
    			# but would work against LDAP source.
    getent group
    getent group wheel	#  
    getent hosts		# get list of hosts , but don't retrieve from DNS.  think cat /etc/hosts
            
    
    
    perl -e "print crypt('clear-text-password','salt');"
    			# generate the CRYPT encrypted version of the string
    			# clear-text-password usnig the first two letter as
    			# the salt to seed the encryption.
    			# CRYPT is the default password encrypting scheme
    			# for solaris /etc/shadow and many other unices.
    			# {CRYPT}encrypted entry can be used in ldif file
    			# for password import into LDAP POSIX User account.
    

    FreeIPA

    FreeIPA: An Integrated system that provides Directory Server (LDAP), MIT Kerberos, NTP, DNS, Dogtag Certificate System. See FreeIPA doc for more details.

    FreeIPA comes with CentOS/Rocky etc, to the point it is branded together with the distro.
    It provides Radius, MFA/OTP, DNS, certificate signing, all integrated into one.
    systemctl start ipa		# active (exited) status is normal	
    systemctl start radiusd		# active (running) is the normal state, listen on port 1812
    


    It uses apache httpd to host the web site, and it does make self RCP calls via the hostname URL, it is said cannot change port 443,80 to something else cuz such RCP calls will break. I suppose if they are encoded in the URI of the code then changing /etc/services won't cut it.
    ssh port forward for 443 only won't cut it either. Would need to setup a SOCKS proxy (eg in Firefox) and also update local /etc/hosts file to have IP of the FreeIPA server. Maybe easier just use command line tool :)

    Allowed radius clients list configured in /etc/radius?/ client.conf /etc/ipa ?

    config files

    /etc/ipa/default.conf
    	enable_ra 	# this has to do with certification ops on IPA replica, see https://www.freeipa.org/page/Howto/Promoting_a_self-signed_FreeIPA_CA#:~:text=Enable
    
    Logs:
    /var/named/data/query.log
    /var/named/data/query_errors.log
    /var/named/data/named.log
    
    

    Ports and Firewall

    https://web.mit.edu/kerberos/krb5-1.5/krb5-1.5/doc/krb5-admin/Configuring-Your-Firewall-to-Work-With-Kerberos-V5.html
    1. 1812 udp is default : radius (if not running, rever to use ldap protocol?) radtest command use this. firewall to allow local network clients
    2. 1813 udp is default : added by freeipa, firewall to allow local network clients only
    3. 8080: there is a tomcat server running, block this from external access is ok
    4. 443, 80: hard coded RCP calls, dont change them. firewall them (only allow localhost?)
    5. 8443?
    6. 88 tcp/udp: kerberos-sec (listen by krb5kdc)
    7. 389, 636: ldap, ldapssl protocol
    8. 464 tcp/udp: kerberos
    9. 749 tcp : kerberos-adm (not mandatory?), udp?
    10. 754 tcp : kprop requests needs to get through FW to the remote KDC
    11. 53 tcp/udp: open if have DNS server running. firewall to allow desired clients to connect.
    12. 123 udp for ntp
    13. # check ports are reachable from a client machine.  
      # open|fitered is ok
      sudo nmap -e enp0s9 -sUT -p53,123,80,88,443,8443,8080,389,464,636,749,754,1812-1813 freeipa
      
      
      ipa-client-install  message about firewall requirement
      
      Please make sure the following ports are opened in the firewall settings:
           TCP: 80, 88, 389
           UDP: 88 (at least one of TCP/UDP ports 88 has to be open)
      Also note that following ports are necessary for ipa-client working properly after enrollment:
           TCP: 464
           UDP: 464, 123 (if NTP enabled)
      
      
    TBD
    /etc/krb5.conf has
    
    [realms]
      G.LOCAL = {
        kdc = freeipa.g.local:88
        master_kdc = freeipa.g.local:88
        admin_server = freeipa.g.local:749
        kpasswd_server = freeipa.g.local:464
        default_domain = g.local
        pkinit_anchors = FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem
        pkinit_pool = FILE:/var/lib/ipa-client/pki/ca-bundle.pem
      }
    
    

    User commands

    # sn50 is an example LOGIN (username), think alice, bob, carol
    
    ipa user-show  sn50		# show info of specific user, exact spell, by userlogin 
    ipa user-show      		# no argument will get a prompt
    ipa user-find 			# list all users in ipa db (think to getent passwd)
    ipa user-find  tin		# find any account containing specified patter "tin" in userlogin, first and last name.  case insensitive search
    ipa user-find --all tin		# --all provide all radius info
    
    ipa user-find --all | egrep login:\|expiration:		# list users and their password expiration date.
    ipa user-find --all | egrep login\|authe\|disabled	# display username, whether otp created, and if account is disabled
    
    [ref: https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/pwd-expiration.html ]
    ipa group-find  --all | egrep name:\|GID:\|users:       # display groups
    
    ipa user-mod --password 	# user can change password their own password
    
    # change when password expires                    yyyyMMddHHmm??Z  last few maybe timezone
    ipa user-mod sn50 --setattr=krbPasswordExpiration=20121231011529Z
    
    ipa otptoken-add 		# add OTP/MFA. QR code can be displayed in most terminals these days.
    ipa otptoken-add --type=totp --owner=sn51 --desc="My soft token1"
    ipa otptoken-del  sn50 	# remove token
    # removing the token is not needed to change auth back to password
    ipa user-mod sn50 --user-auth-type=password
    
    # once OTP is added, ssh login prompt change from password to First Factor/Seconf Factor
    # and must use both password and token to login
    # User can run "otptoken-add" multiple times and have more than one token, can use either to login
    
    # sometime enforcement of otp still need root to run:
    ipa user-mod USERNAME --user-auth-type=otp
    # this clause need to show when doing   ipa user-show :
    #   User authentication types: otp
    
    # change username
    ipa  user-mod joe50 --rename=joe126
    
    ipa group-find
    
    ipa pwpolicy-show                     # there is a default global policy if no group policy is defined
    ipa pwpolicy-show --user=sn50
    ipa pwpolicy-mod --minlife=1 --maxlife=90 --history=3	# modify system default pw policy, minlife=1 maybe bad, user can't change password if they set a bad one till a day later...
    ipa user-show sn50 --all | grep expiration 
    
    ipa pwpolicy-mod ... to have differing password complexity requirements (for everyone)  --minlength --charclasses
    
    ipa pwpolicy-add exampleGroup --minlife=7 --maxlife=49 --history= --priority=1 
    [ ref: https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/Setting_Different_Password_Policies_for_Different_User_Groups.html ]
    
    # not sure about password complexity.  
    # especially if have OTP, then first token for password is acceptable to be a simple PIN.  
    # How to do this?  ++
    
    
    # add/change user to ipa DB
         ipa help user-mod  # much better than the man page!
    sudo ipa user-add jsmith --first=John --last=Smith                   --email=johnls@example.com --homedir=/home/work/jsmith
    sudo ipa user-add jsmith --first=John --last=Smith --uid=6667 --gidnumber=6667 --email=johnls@example.com --homedir=/home/work/jsmith
    sudo ipa user-add jsmith --first=John --last=Smith --manager=bjensen --email=johnls@example.com --homedir=/home/work/jsmith
    sudo ipa user-del jsmith  # delete/remove user account.  no confirmation asked!
    
    sudo ipa user-mod sn50 --password                    # prmopt to enter new password
    sudo ipa user-mod sn50 --uid=6666  --gidnumber=6666  # group entry for new gid is auto added
    sudo ipa user-mod sn50 --shell=/bin/bash 
    
     --user-auth-type=['password', 'radius', 'otp', 'pkinit', 'hardened']
                            Types of supported user authentication
    
    
    ipa group-add  docker                  # create new group "docker", get assigned random gid
    ipa group-mod  docker     --gid=396
    ipa group-add  dockerroot --gid=397
    ipa group-show dockerroot 
    
    # add add as secondary group membership, ie
    # modify group entry, add user to group
    ipa help group-add-member
    ipa group-add-member    docker     --users=sn50 --users=tin   # add multiple users to existing group
    ipa group-add-member    dockerroot --group=docker             # support "indirect member", id -a seems to report things correctly.
    ipa group-remove-member dockerroot --users=sn50               # remove member, but not if it is from a nested/indirect group
    
    ipa group-find --user=sn50    # find groups that user sn50 is a member of
    
    
    ipt user-mod --setattr=key=value?   # for custom ldap attributes? fuzzy about syntax.  POSIX attrib can just use build in support for --uid --gidnumber etc
    
    
    
    
    

    Admin commands

    kinit 	# initialize Kerberos system, restart timer
    
    sudo ipa user-disable User_LoginName
    sudo ipa user-enable  User_LoginName
    
    ipa user-mod --password alice		# this apparently need the tomcat server to be operational to work
    
    
    ipa user-add	# interactive prompted user addition, but only ask for first, last, and username.  
    
    radsniff -X	# trace/sniff ipa connectivity request?
    
    
    ## How to remove the "change password on first login" ?    esp using cli
    ## How to remove password expiration ?  or change expiration in cli ?
    ## how to change uid/gid ?   maybe ipa user-mod ... 
    
    
    ipa group-del docker	# delete group named docker
    
    
    

    IPA Server install commands

    # for IPA server, NOT client.  
    ipa-server-install 
    ipa-server-install --uninstall
    
    
    [root@freeipa]# systemctl list-unit-files | grep ipa
    ipa.service                                                            enabled
    ipa-ccache-sweep.service                                               disabled
    ipa-custodia.service                                                   disabled
    ipa-dnskeysyncd.service                                                disabled
    ipa-ods-exporter.service                                               disabled
    ipa-otpd@.service                                                      static
    multipathd.service                                                     enabled
    ipa-ods-exporter.socket                                                disabled
    ipa-otpd.socket                                                        disabled
    multipathd.socket                                                      enabled
    ipa-ccache-sweep.timer                                                 enabled
    
    # these are started by freeipa?? 
    krb5kdc.service                                                        disabled  
    radiusd.service                                                        disabled
    
    systemctl status really just call 
    /usr/sbin/ipactl 
    
    
    
    systemctl status reporting "active (exited)" is fine.
    running processes:
    
    [root@freeipa data]# ps -ef | grep ipa
    ipaapi     91875   91868  1 12:45 ?        00:00:01 (wsgi:ipa)      -DFOREGROUND
    ipaapi     91876   91868  1 12:45 ?        00:00:01 (wsgi:ipa)      -DFOREGROUND
    ipaapi     91877   91868  1 12:45 ?        00:00:01 (wsgi:ipa)      -DFOREGROUND
    ipaapi     91878   91868  1 12:45 ?        00:00:01 (wsgi:ipa)      -DFOREGROUND
    root       91887       1  0 12:45 ?        00:00:00 /usr/libexec/platform-python -I /usr/libexec/ipa/ipa-custodia /etc/ipa/custodia/custodia.conf
    ods        92359       1  1 12:45 ?        00:00:01 /usr/libexec/platform-python -I /usr/libexec/ipa/ipa-dnskeysyncd
    
    
    kdcproxy    7742    2844  0 Apr16 ?        00:00:04 (wsgi:kdcproxy) -DFOREGROUND
    root       15276       1  0 15:03 ?        00:00:00 /usr/sbin/krb5kdc -P /var/run/krb5kdc.pid
    
    radiusd    15198    1639  0 14:42 pts/0    00:00:00 radiusd -X    # debug session running here
    
    
    journalctl -u ipa
    
    
    

    FreeIPA DNS server

    The DNS in FreeIPA is wrapper around bind-dyndb-ldap, which is based on bind. so, config and doc for bind would apply.
    ipa dnszone-find 			# list all dns zones managed by this server
    
    ipa dnsrecord-find g.local		# list all dns record for the dnsZone named g.local
    ipa dnsrecord-find g.local  n00		# get entries like n00.g.local, pxe-n00.g.local (ie substring search on hostname n00)
    ipa dnsrecord-find g.local | grep "Record name"
    ipa dnsrecord-find 16.8.10.in-addr.arpa.	# reverse PTR zone
    
    
    Adding DNS zone
    ipa dnszone-add 16.8.10.in-addr.arpa.
    
    Adding DNS host record
    ref:
  • https://www.freeipa.org/page/Howto/DNS_classless_IN-ADDR.ARPA_delegation#
  • https://blog.khmersite.net/2020/12/freeipa-adding-new-dns-record/?msclkid=234a796acfcc11ec9a6b232e7b9ac9bf
    Ensure reverse dnszone exist or reverse record addition will fail. (but forward record still added)
    ipa dnsrecord-add g.local  n00 --a-rec 10.8.16.100 --a-create-reverse  # "forward" A record
    ipa dnsrecord-add g.local  n01 --a-rec 10.8.16.101 --a-create-reverse 
    
    ipa dnsrecord-add g.local  alias00     --cname-rec=n00      # CNAME alias record
    
    round-robin recods for load balancing
    
    ipa dnsrecord-add g.local  vasttest --a-create-reverse  --a-rec 10.8.16.50
    ipa dnsrecord-add g.local  vasttest --a-create-reverse  --a-rec 10.8.16.57
    
    # change TLS?
    
    add missing reverse PTR records:
    ipa dnsrecord-add 16.8.10.in-addr.arpa.  128  --ptr-rec c00.g.local.   # ie add 10.8.16.128
    ipa dnsrecord-add 16.8.10.in-addr.arpa.  100  --ptr-rec n00.g.local.  
    #                                        ^^^-------- last octet
    
    modifying renaming record
    ipa dnsrecord-mod example.com www --a-rec 10.1.1.1 --ip-address 10.1.1.2
    
    changing ttl
    ipa dnsrecord-mod g.local vasttest --ttl=3600
    
    deleting record
    ipa dnsrecord-del g.local  vasttest --a-rec 10.8.16.50 
    ipa dnsrecord-del 16.8.10.in-addr.arpa.  58  --ptr-rec vasttest.g.local.   # ie del 10.8.16.58 which has hostname vasttest.g.local
    
    DNS forwarding, recursive query problem:
    see RH solution doc
    forwarding is not working, check as:
    dig @freeipa.local  google.com
    # WARNING: recursion requested but not available
    
    Fix:
    On webUI, Network Service, DNS Global Config, 
    Forward policy: 
    - Forward first (most permissive)
    - Forward only
    - Forwarding disabled (no outside name resolution then).
    
    Use ACL to restrict which client can query the local DNS server:
    
    on freeipa server, edit 
    /etc/named/ipa-options-ext.conf
    	// allow recursion per https://access.redhat.com/solutions/5753431
    	allow-recursion { trusted_network; };
    	allow-query-cache  { trusted_network; };
    
    /etc/named/ipa-options-ext.conf
    
    	acl "trusted_network" {
    	 localnets;
    	 localhost;
    	 192.168.0.0/16;
    	};
    
    systemctl restart named-pkcs11
    
    
    Global Forwarder
    Configure a global forward on the IPA DNS server, so external names can be resolved (if desired). ref:
  • https://serverfault.com/questions/1081774/how-are-external-urls-resolved-by-freeipa
  • https://www.freeipa.org/page/V4/Forward_zones
  • https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_identity_management/assembly_troubleshooting-authentication-with-sssd-in-idm_configuring-and-managing-idm#doc-wrapper
    # see existing config
    ipa dnsserver-find
    ipa dnsserver-show
    ipa dnsforwardzone-find
    
    
    # add global forwarder (for all external dns):
    ipa dnsconfig-show
    ipa dnsconfig-mod --forwarder=131.243.5.1
    #ipa dnsconfig-mod --forwarder=8.8.8.8 
    #ipa dnsconfig-mod --forwarder=8.8.8.8 --forward-policy=first  # alt: only|none
    #XX ipa dnsconfig-del --forwarder
    
    
    Server will check DNS forwarder(s).
    This may take some time, please wait ...
    ipa: WARNING: Forwarding policy conflicts with some automatic empty zones. Queries for zones specified by RFC 6303 will ignore forwarding and recursion and always result in NXDOMAIN answers. To override this behavior use forward policy 'only'.
      Global forwarders: 8.8.8.8
      Forward policy: first
      IPA DNS servers: ...
    
    
    ipa dnsconfig-show
    ipa dns-server-show    # seems to use a diff forwarder
    
    
    ipa dnsserver-find
    	Forwarders: 10.243.5.1
    	Forward policy: only
    	forward only config as referenced by https://www.freeipa.org/page/V4/Forward_zones#forward-policy 
    	allow for central DNS server to provide hostnae resolution filtering, eg prevent phising attack, etc.
    
    
    

    FreeIPA for signing certs

    The DogTag project for signing cert is bundled into FreeIPA, see FreeIPA PKI

    This post on Creating certs and keys for services using FreeIPA (Dogtag) has a good overview of the process.

    And HOW DO I GET A CERTIFICATE FOR MY WEB SITE WITH IPA? list some useful relevant ipa commands

    FreeIPA for OpenVPN gist

    
    kinit admin
    ipa dnsrecord-find  hulk.local		# list all dns record for the named zone hulk.local
    ipa dnsrecord-add   domain      hostname
    ipa dnsrecord-add   hulk.local  www
    ipa dnsrecord-add   hulk.local  vpn
    
    ipa dnsrecord-add hulk.local  vpn  --a-rec 192.8.17.19
    ipa dnsrecord-add 17.8.192.in-addr.arpa. 19 --ptr-rec vpn
    
    ipa host-add  www.hulk.local
    ipa host-add  vpn.hulk.local
    
    ipa service-add    openvpn/vpn.hulk.local
    ipa service-add    HTTP/www.hulk.local
    
    ipa service-add-host --hosts=ipa-server.test.lan HTTP/www.test.lan
    
    ipa-getcert request -r -f /etc/pki/tls/certs/vpn.hulk.local.crt -k /etc/pki/tls/private/vpn.hulk.local.key -N CN=vpn.hulk.local -D vpn.hulk.local -K openvpn/vpn.hulk.local
    
    copy .crt and .key files to www/vpn server
    
    getcert stop-tracking -i 20220211224159	# remove if need to redo eg cuz typo
    
    ipa service-find  | grep "Principal name"
    
    
    ipa-getcert list 	# list all tracked cert.  it auto renew before expiration.  just need to copy .crt and .key file to server.
    	
    
    

    FreeIPA Troubleshooting

    FreeIPA Priviledge Separation list the components, their config, and log
    FreeIPA management framework   
    - /etc/ipa/default.conf
      debug = True
      write to /var/log/ipa/client.log
      or just run ipa command and output will include debug.
    - /etc/ipa/server.conf
    
    Apache httpd
    file /var/lib/ipa/gssproxy/http.keytab
    
    GSS-Proxy
    /etc/gssproxy/gssproxy.conf
    journalctl -u gssproxy
    
    
    
    cache storage
    - /usr/lib/tmpfiles.d/ipa.conf
    
    KDC operations
    - /var/log/krb5kdc.log
    - klist -A
    - file  /etc/krb5.keytab 
    
    Other
    - /var/log/dirsrv/slapd*
    
    
    
    user that can't login, this could help:
    passwd Username --delete
    It "it blows away some local pw cached in some db somewhere locally and removes it from /etc/shadow (maybe runs pwconv)".  Thx Karen!
    
    
    
    

    kerberos

    KDC
    
    ss -tulp | grep kdc
    /var/log/krb5kdc.log
    
    
    
    Kerberos client
    eg client using FreeIPA/Radius/LDAP
    kinit
    ipa user-find --all jsmith
    
    # each user that wants to run ipa command need to have a valid ticket, run kinit if tix expired
    # expired password may not login eg via ssh
    
    Troubleshooting
    realm list https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/trouble-general
    Set the KRB5_TRACE environment variable to the /dev/stdout file to send trace-logging output to /dev/stdout:
    KRB5_TRACE=/dev/stdout ipa cert-find
    KRB5_TRACE=/dev/stdout ipa user-find jsmith
    
    
    HISTCONTROL=ignorespace
      # nas-port-number is essentially the outbound port number on localhost running the radtest cmd
      # secret is the string in /etc/raddb/server used by client to connect to radius server
      radtest [OPTIONS] user passwd radius-server[:port] nas-port-number secret [ppphint] [nasname]
      radtest jsmith jSmithPassword ipa.test.org:1812 2468 radServerSecret
    the nas-port-number 2468 is a dummy due to relic , it is NOT used as local port
    radtest provided by freeradius-utils rpm
    ref: https://support.microfocus.com/kb/doc.php?id=7014552
    
    
    sss_cache -E  		# clear --everything  in sss cache
    getent passwd sn50
    id -a sn50
    
    
    
    Sometime kerberos act up. Ref: Unable to login as an AD or IPA user due to "4 (System error)" via SSSD on Red Hat Enterprise Linux. - Red Hat Customer Portal (paywalled)
    kdestroy -A
    kinit admin
    
    mv /etc/krb5.keytab /etc/krb5.keytab.bak2023-0427
    
    ipa-getkeytab -s freeipa.g.local -p host/freeipa.g.local -k /etc/krb5.keytab              
    Redirecting to /bin/systemctl start sssd.service
    
    
    Tmp workaround: 
    Disabling keytab validation in /etc/sssd/sssd.conf configuration file can also be used to work around the issue until it's fixed. This would allow AD/IPA users to login.
    krb5_validate = False
    
    
    
    ipa host-find  --all radiusClientHostname | grep enroll    # host should be enrolled (ie joined to the radius realm)
    ?? host-mod unenroll ?  (then host has to go thru ipa client setup process to rejoin the realm.  think AD host joining domain)
    ipa host-add  ipa-client-hoostname.fqdn
    ipa service-add HTTP/ipa-client-hoostname.fqdn
    
    
    ipa host-find vpn --raw			# it is --raw , not --long or --full #searchfood
    ipa host-find vpn --raw			# some host may have forced join auth method, eg krbprincipalauthind: otp
    ipa host-mod --auth-ind=""  myhostname  # remove the forced join auth method 
    
    
    ipa help host
    
    ipa host-show hostname
    
    re-enroll client, see ipa-client-install --help
    
    # Note that a host entry is like windows AD host joined to the realm
    # DNS entry does NOT show up under host-find, use dnsrecord-find instead
    
    ipa dnsrecord-find g.local	#  # list all dns record for the dnsZone named g.local
    ipa dnsrecord-find 1.168.192.in-addr.arpa.        # reverse PTR zone
    
    ipa dnszone-find
    
    
    ~~~~~
    
    https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/retrieve-existing-keytabs
    
    
    ipa-getkeytab -s freeipa.g.local -p host/vpn.g.local -k /tmp/client.keytab
    # gen new keytab, invalidate old one
    
    ipa-getkeytab -r -s freeipa.g.local -p host/vpn.g.local -k /tmp/client.keytab
    # check keytab, be sure to use -r to reuse, or get new one and old one is invalidated
    
    cp -pi /tmp/client.keytab  /etc/krb5.keytab
    
    
    
    klist -A
    klist -ek /etc/krb5.keytab	# list krb principal and tickets in keytab/cache file, but may not be valid?
    
    kinit -kt /etc/krb5.keytab      # authenticate a host
    
    log in IPA server: /var/log/dirsrv/slapd*/
    access
    error
    
    
    
    kvno ... verify key numbers
    
    

    sssd

    
    
    
    sssctl domain-list
    sssctl domain-status g.local		# if show offline, then problem!
    sssctl domain-status g.local --start
    
    
    sssctl user-checks  sn50
    
    sssctl user-show  -u 6666
    
    
    log:
    setting /etc/sssd.conf  with debug log would provide lot more info
    /var/log/sssd/
    
    

    Reference

    Online


    Red Hat


    IBM AIX


    Books



    [Doc URL]
    tiny.cc/LDAP
    https://tin6150.github.io/psg/ldap.html
    http://tin6150.github.io/psg/ldap.html
    (cc) Tin Ho. See main page for copyright info.
    Last updated: 2022-07-06


    hoti1
    bofh1