yes – i was trying to fix it myself…
but frankly, i wasn’t able setup a debug/development installation to test the necessary fixes.
it’s really a pity – the necessary code changes to fix the issue itself are quite trivial and easy to write, but the complexity and fragmented source organization of rancher makes it very uncomfortable and time consuming for foreign participants unfamiliar with all its idiosyncrasies to change/test anything.
i still think, there are only two changes needed:
on the UI/API side we need to remove the
field-required attribute for
serviceAccountPassword if they are used in
the authentification callbacks have to use simple access without explicit DN-binding if no username/passwort is given.
in the case of the ldap library used by rancher (ldap.v2) this is handles a little bit different than e.g. for openldap bindings. openldap uses empty username/passwort options to enable this kind of access. that’s very close to its representation in the ldap network protocol and the relevant specifications. but the actual library used by rancher needs another workaround to use this kind of anonymous access. in this case simple anonymous access will be chosen automatically for a search, if no explicit other binding are used before. it’s therefore only necessary to look in
rancher-auth-service/providers/ldap/ldap_client.go:newConn(), if username/passwort fields are empty and bypass the
lConn.Bind(serviceAccountUsername, l.Config.ServiceAccountPassword) command in this case.
i hope, that works…
but again – this changes look quite trivial and just mimic, how LDAP is usually used in unix environments resp. what’s necessary to fulfill the requirements specified in the relevant RFCs.
it’s only the complexity of ranchers build and deploy system, which i couldn’t master as developer ad hoc.
and as a gerneral side note about the OPEN SOURCE nature:
meanwhile i’m working and developing nearly exclusive using open source tools and operating systems for nearly three decades! – really. i’know, what it means!
and believe it or not, i’m able to differentiate between open source software, in the sense of maximized transparency and collective development efforts, and those more fashionable approaches, where proclaimed open source terms are just camouflage proprietary and paternalistic business strategies…
and in this particular case i had to evaluate a few orchestration solutions for a corporation. i just tried to integrate their existing LDAP administration infrastructure and found this obvious issue.
sure, i simply could have worked around it, but as i stumbled over it in ‘evaluation’-mode, i didn’t choose this option. instead i wrote a bug report – that’s IMHO the most useful way simple ordinary users have to participate and help in open source development.
later, when i found all this other ignored similar bug reports, i really felt alarmed. and when i finally saw you response here in this forum, my judgment about your software and the report i have to give about it was more are less clear and inevitable:
i just can summarize: stay away from this software!
not because it’s developers are demanding, that users have to fix bugs themself – that’s something i could perhaps accept – but because of the ignorance concerning standard compliance and compatibility with non-proprietary solutions. that’s something, i really can’t stand. IMHO it’s an infallible indicator for software we should better avoid.