After time off in early Fall, November filled up with project meetings and task lists.
We’re working with offsite server image farms, and the first order of business after getting network routing up was connecting the application servers to our Active Directory for the resemblance of single sign on.
Some basic driver code, some salt and pepper, and viola, network names resolve and I can use my well known account. Mostly. And that’s where the fun began.
The winbind set up had several distinctions from the tool we use on AIX for AD connectivity. There are extended attributes that don’t seem to pass to windbind. Account ID numbers were provisioned differently. And the biggest syntax difference we encountered was needing to pass the main domain name along with the account name to connect at the system level (SAP GUI connection is a completely different adventure I’m not on yet).
Shell level access and secure file copies worked as expected, with the exception of the Windows domain name. It needed either a backslash or an at sign, both of which have specific meanings on normal Unix shells. Escaping them is easy enough once you realize it is needed. The problem is when applications don’t behave the same way.
First try was a well known file transfer GUI app. Tried all the levers and push buttons, never connected.
I think I figured out where the handshake failed, though unless there are undisclosed menus or switches, I was lost.
The second one succeeded with little effort. Note the two “@” signs in the connection string box. And yeah, I tried backslashes and at signs in various permutations.
In other vendor ticket upload processes, I’ve been able to use command line syntax like “user@domain”@host where the parts inside the quotes are the account identifier. We love special characters.
The Windows domain name being part of the account has repercussions on the basic UNIX user status command family (“w”, “who”, et al). This distro with winbind from Samba truncates the account name and only shows the domain, not the user,
DOMAIN\user@host:~> who -u root pts/0 2016-12-04 21:25 old 648 (18.104.22.168) root pts/1 2016-12-08 08:47 old 1593 (22.214.171.124) root pts/2 2016-12-07 17:42 old 905 (126.96.36.199) root pts/3 2016-12-05 06:31 old 718 (188.8.131.52) DOMAIN\user pts/4 2016-12-12 08:44 . 608 (x.y.com)
Next step is to debug AD group permissions to filter the community, and after that, automation agents, monitoring and ticker interfacing, and maybe some shell scripting. No Perl though. I’m swearing it off on Linux.