Skip to main content

I made a GIF!

Cisco UCM and Novell eDir

Successfully integrated Cisco Unified Communications Manager 8.5.1 (VOIP) with our central authentication and directory service Novell eDirectory 8.8.3 (LDAP) after 2 days research and testing. All 15,000+ users were imported quickly and with no issues. While Novell eDirectory is not officially Cisco supported, supported LDAP directory Oracle SunOne is remarkably similar.


The LDAP SSL certificate CN and LDAP server hostname must match correctly.  The following changes were made to integrate CUCM with our enterprise directory services on Novell eDir:
  1. LDAP attribute uid is a secondary mapping for eDir CN.  The eDir attribute uniqueID does not have a LDAP mapping.
  2. Search results are increased from 200 to 1000 entries.
  3. Search timeout is decreased from 20 to 0 (unlimited).
  4. Persistent search is disabled (default is enabled).
  5. The BindDN user object is permitted 5 concurrent connections (increased from 1).
The eDir/LDAP services were restarted via the ndsmanage utility (SSH CLI).  The remaining work to do is popule the following CUCM required attributes via Novell IDM:
  • inetOrgPerson attribute: "manager"
  • inetOrgPerson attribute: "departmentnumber"
  • inetOrgPerson attribute: "telephonenumber"
  • inetOrgPerson attribute: "mail"
  • inetOrgPerson attribute: "title"
  • inetOrgPerson attribute: "homephone"
  • inetOrgPerson attribute: "mobile"
  • inetOrgPerson attribute: "pager"
The following CUCM required attributes were already in Novell eDir:
  • inetOrgPerson  attribute: "uid" <mapped to CN>
  • inetOrgPerson  attribute: "givenname"
  • inetOrgPerson  attribute: "initials"
  • inetOrgPerson  attribute: "sn"
This is not required for the phone deployment, but is needed eventually for the phone-based directory service.
 
References:
Observe secure LDAP conversations with NDSTrace 
(URL http://support.novell.com/docs/Tids/Solutions/10062292.html )

Andy Swiffin's "Integrating Cisco Unified Communications Manager version 7 with eDirectory"
(URL http://www.novell.com/communities/node/8869/integrating-cisco-unified-communications-manager-version-7-edirectory )

Comments

Popular posts from this blog

Cisco ASA ICMP packet-tracer

Occasionally devices fail to respond to a ping.  This can result from devices being off-line, having a local firewall enabled or the perimeter firewall configuration.  The Cisco ASA ICMP packet-tracer options differ from the TCP or UDP command options.  An example is below: packet-tracer input outside icmp A.B.C.D 8 0 E.F.G.H The ICMP type is "8" (echo request) with code"0" (none).  There are no options on destination IPv4 address E.F.G.H. Complete ICMP documentation at URL http://www.iana.org/assignments/icmp-parameters/ Complete Cisco ASA packet-tracer documentation at URL http://www.cisco.com/en/US/docs/security/asa/asa80/command/reference/p.html#wp1878788

Xfce4 lock screen not working

Xfce4 would not start a screensaver on my Linux system.  Researching it, it ran xflock4 from the command line ad received an error: Property "/general/LockCommand" does not exist on channel "xfce4-session". To fix this, additional configuration needed, but no hacks. First, verify xflock4 and xfconf-query are available. $ which xflock4 xfconf-query /bin/xflock4 /bin/xfconf-query Next  install a lock screen package that provides 'xlock', 'slock', 'i3lock' or similar.  $ sudo yum install -y xlockmore-gtk i3lock Last, add an executable (with options) as /general/LockCommand in the xfce4-session settings. $ xfconf-query -c xfce4-session --create -p /general/LockCommand --set "xlock -mode matrix" --type  string $ xfconf-query -c xfce4-session --create -p /general/LockCommand --set "i3lock -c 000000" --type string Test by running xflock4 from the command line or through the GUI.

X11 Forwarding issue solved

TL;DR Disabling IPv6 necessitates SSHd AddressFamily is "inet" for X11 Forwarding to work. Issue OpenSSH assumes both IPv6 and IPv4 protocols are enabled, and default SSHd AddressFamily value "any" is valid. Quickly skimming the OpenSSH source code, it was not obvious why SSHd does not fail gracefully, selecting only an available IP address family. Therefore, for X11 Forwarding to work correctly, in /etc/ssh/sshd_config we must choose: Defaults - IPv6 enabled and SSHd AddressFamily value " any " Custom - IPv6 disabled and SSHd AddressFamily value " inet " Background PuTTY was not creating a $HOME/.Xauthority file on ssh login and no X11 applications would run, despite setting $DISPLAY.  PuTTY was correctly configured with: X11 Forwarding enabled X display location empty Remote authentication protocol MIT-Magic-Cookie-1 X authority file for local display empty On the initial ssh login there should be a .Xauthority notic