I hear you. Countless (literally) days, weeks, months now but I gave up after the unprofessionalism of the bug ticket I last opened, and had closed due to being one month old with no activity. Yet each week of those four weeks the owning engineer/programmer made a single entry stating "not this week, too busy, maybe next week" or something to that effect. Entire lab environment built for my "lab" that travels with me when I design and build a new datacenter or datacenter "pod" within an existing dc for my customers. Needing to generate traffic, both block and file level to emulate day to day file shares and transfer, plus dedicated SAN booting from iSCSI LUNs for some guests and hosts. With one physical and one virtual for replication between nodes etc. LDAP needed for authentication of all devices in my "pod". This is production to me, and used as a temporary environment on new datacenter networks as part of my resiliency and redundancy testing. Prior to handing off to customer for live traffic I spend days using this gear emulating real world scenarios to prove hardware and sofware as well as my design. This was HUGE exposure with many clients inquiring specifically into my Storage/SAN hosts and wanted help setting FreeNAS up in their lab right then and there. Now, iSCSI wont work if I update it above 2015-07162300 which appears to delete the /etc/ctl.conf. But for LDAP network is a single Cisco switch, servers using LDAP in that common switch, common vlan/subnet, no routing, standard mtu yet only assistance I got was diagnosed as a network "issue" c'mon the network engineer gets the network scapegoat....Well I gave up, but left configured and started allowing daily builds to attempt to bind each day one was released as an automated or automatic way of checking. Knowing I went thru all parameters, and majority of users doing the same thing appear online to have consistently same failures/issues I am having, some exact down to the smallest detail. Well June 27th 0630hrs nightly image release booted up and went green !!! meaning it did bind with Open Directory, and then Active Directory as well as others prior have but this time it marked a milestone being the first time with security enabled !! yes with ssl/tls, my certificates generated for this system specifically, it started working.
Now another consistency though, for the Kerberos I set the realm, but MUST leave the keytab untouched. In that version and in all tested since then if I attempt to select a keytab file in the GUI drop down menu the FreeNAS GUI crashes !!! 2-3 pages like "dump" for django and nginx if I recall correctly. So working around the GUI for keytab I got it working with AD 2008, AD 2012, and Open Directory with is always 10.10 Yosemite. The next image worked as well, stable version worked but then it broke again. I left configured on nightly version for awhile then abandoned altogether as its to inconsistent. Some days the groups show, but no users, then users but no groups, or they all show, and all works via CLI perfectly, but authentication fails using tested and working accounts in CLI and its just up and down like that to the point I am fed up. Need a new NAS I think because centralized authorization and CONSISTENCY is required for my job. I am the trusted advisor as many of my clients call me, and I was the FreeNAS cheerleader until recently. I was a traveling commercial giving live demo's surprising many customers using EMC and NetApp in their datacenters I am building. Small and Medium businesses almost always call me back or pull me aside to speak to FreeNAS and how it can help them out, many large Enterprises inquire just the same or want in their lab for SAN/NAS side. Never asked for anything but some LDAP config assistance and testing due to SO MANY people having same issue. Instead you get insulted by the bully watch dog in the forums speaking to technical aspects he has no business guessing about, let alone speaking on as an authority on the subject. Or your bug gets closed for inactivity caused by internal folks.....Keep me posted if you find anything, but hey one more point I of contention for me that possibly affects you. The IdMap backend settings documented int the config guide, back then and today, still. I found a bug ticket someone opened on behavior of the IdMap backend changing or not working in his network and the programmer berated him asking why he used "that" setting. he said its clearly incorrect and for AD you should be using "this" setting instead. We both changed that setting and BAM,again green connection where for weeks it was red and inoperable. If anyone would have listened I would have raised issue again and calling out exact pages its documented wrong per that particular engineer. I remember customer with the issue stating the document statement is why he had it selected but all this time later, nothing updated in the document that I have seen.
All in all with all this non working LDAP time over the past 90 days, I have had only about a week or two of time it was green or "up" and connected. Thru those days of testing etc. not once ever did it work across the board. NEver did an account authenticate properly 100% of the time in both the CLI window and then from a workstation or server once the CLI tested successfully. That and groups/users appearing and disappearing was irritating but the end all be all is once I finally saw SSO/Kerberos working across both windows and macs to freenas in a fashion that started looking acceptable something of course would pop up. In my case, and when I called it, the GUI started flaking again. Keytab still NEVER could be filled in since june 27th and it started connecting, but this new issue when clients authenticated fine in CLI and across network using shares the Storage Tab, Permissions, Groups were fine, Users didn't show, only local freenas users.. but CLI showed them in testing... cant keep going but this loop is likely never ending so like ldap on freenas, iscsi, and likely freenas unless drastic changes pop up this weekend, I'm calling it.
Good Luck !! Hope yours goes better than mine
dave
