AD Integration
we need to use AD, specifically AD groups, to manage access to loginsight, and we need it to be a secure connection.
For us, the best integration would be to have these LDAP connection settings:
- Host & Port
- SSL enabled
- Bind DN & Bind DN Password
- User base DN
- Group base DN (Use Nested groups)
I tried to configure AD based on LogInsight 1.5 beta documentation and use secure ldap protocol
Document: log-insight-15-administration-guide.pdf
small typo - /usr/lib/loginisight/application/etc/loginsight-config-base.xml
should be - /usr/lib/loginisight/etc/application/loginsight-config-base.xml
Issue 1
"LogInsight EMS Admins" - group in AD
1. change config:
add <ad-protocols value="LDAPS" /> For specifically using LDAP with SSL only
- how to verify it uses ldaps? is it really ldaps?
2. service loginsight restart
Issue 2 (known - ESX stopped sending the data)
3. Lost the data
The host "loginsight:514" has become unreachable. Remote logging to this host has stopped.
4. Administration -> Integration -> vSphere
ESXi hosts configured to send logs to Log Insight
click "View ESXi syslog configuration details..."
Verify list of "Configured" ESXi hosts, select them and "Configure Selected" again
- is it possible to "automate" this when there is a need to restart LogInsight?
5. the data is back – need to verify if we have double entries in ESX logging section
Thanks,
ildus
Hey Ildus - I believe your issue is resolved now. Could you mark this question as answered?
Hey Ildus,
* Typo - can you confirm as /usr/lib/loginisight/application/etc/loginsight-config-base.xml should be correct
* Issue 1 - assuming you have trusts established between AD domains then it should work. Having users in different domains should not be an issue as we use the binding user to validate the users/groups. As long as the binding user specified has permission to access the users/groups across domains, this should work. Can you elaborate a bit more on what you are experiencing?
* Issue 3 - expected because of issue 2
* Issue 4 - not today, but we are looking into providing this functionality. The issue is that reconfiguring the hosts can take some time so if we wait for the operation to complete then the restart will take a long time to complete. The alternative is to do it in the background, but then a way to bubble up results would be needed.
* Issue 5 - not sure I follow, can you elaborate?
Hi, Steve, thank you for your reply.
- typo, it is simple copy-paste issue (duh) the pdf has it "/usr/lib/loginisight/application/etc/loginsight-config-base.xml".
- there was one bug I wanted to report - on integration with AD groups.
1 thru 5 were the steps while configuring AD integration, with a restart step (step 2) which led to another known "issue 2" - ESX input loss, with some questions and suggestion...
So, the main issue is AD integration - AD groups specifically.
1. yes, there is a trust between domains. users have different domain and they are not found if not in the domain specified in loginsight config.
2. the AD integration setup screen has only 3 parameters
- domain
- username
- password
this does not make our auth team happy, they want to have more controlled app binds, such us:
- Host & Port
- SSL enabled
- Bind DN & Bind DN Password
- User base DN
- Group base DN (Use Nested groups)
3. I have enabled LDAPS in loginsight-config-base.xml, could you help us to prove it is working?
4. can we see some debug on how authentication is done?
Thank you,
ildus
Hi
Welcome to the communities.
Here are port details .
http://pubs.vmware.com/vsphere-50/index.jsp?topic=%2Fcom.vmware.vsphere.security.doc_50%2FGUID-ECEA7... estridge33.onmicrosoft.com
Amanda63 - I believe that information is for vSphere and not Log Insight.
Ildus - Unfortunately, there is no easy to test LDAPS. If you really wanted to do this then I would recommend installing tcpdump on either LI or the domain controller and sniffing the traffic. What do you mean about debug on how authentication is done?
Yeah, I guess I will use a tcpdump...
we needed a little more info on how the ldap bind to AD is done and how the groups members are looked up...
At this state we have about 50% of EMCers not being able to access loginsight.
Authentication Configuration
Enable Active Directory support - check
Default Domain: corp.emc.com
Username: loginsight
Password: xxxxxxxxxxxxxxxx
User with UPN suffix "xxxxx@emc.com" gets an error:
[2013-11-14 21:12:23.002+0000] [http-443-3 WARN /127.0.0.1] [com.vmware.loginsight.web.actions.misc.LoginActionBean] [Authentication error]
com.vmware.loginsight.commons.exceptions.AuthenticationException: User 'xxxxx@corp.emc.com' not found in domain 'corp.emc.com'.
at com.vmware.loginsight.aaa.krb5.ActiveDirectoryQueryHelper.getUser(ActiveDirectoryQueryHelper.java:75)
at com.vmware.loginsight.aaa.krb5.KrbAuthenticator.queryUserInfo(KrbAuthenticator.java:179)
at com.vmware.loginsight.aaa.ad.ActiveDirectoryAuthenticator.authenticate(ActiveDirectoryAuthenticator.java:76)
at com.vmware.loginsight.aaa.Authenticator.authenticate(Authenticator.java:47)
at com.vmware.loginsight.web.actions.misc.LoginActionBean.validateUser(LoginActionBean.java:83)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at net.sourceforge.stripes.controller.DispatcherHelper$4.intercept(DispatcherHelper.java:267)
at net.sourceforge.stripes.controller.ExecutionContext.proceed(ExecutionContext.java:158)
at org.stripesstuff.plugin.security.SecurityInterceptor.interceptBindingAndValidation(SecurityInterceptor.java:152)
at org.stripesstuff.plugin.security.SecurityInterceptor.intercept(SecurityInterceptor.java:117)
at net.sourceforge.stripes.controller.ExecutionContext.proceed(ExecutionContext.java:155)
at net.sourceforge.stripes.controller.BeforeAfterMethodInterceptor.intercept(BeforeAfterMethodInterceptor.java:113)
at net.sourceforge.stripes.controller.ExecutionContext.proceed(ExecutionContext.java:155)
at net.sourceforge.stripes.controller.ExecutionContext.wrap(ExecutionContext.java:74)
at net.sourceforge.stripes.controller.DispatcherHelper.doCustomValidation(DispatcherHelper.java:253)
at net.sourceforge.stripes.controller.DispatcherServlet.doCustomValidation(DispatcherServlet.java:262)
at net.sourceforge.stripes.controller.DispatcherServlet.service(DispatcherServlet.java:152)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at net.sourceforge.stripes.controller.DynamicMappingFilter$2.doFilter(DynamicMappingFilter.java:431)
at net.sourceforge.stripes.controller.StripesFilter.doFilter(StripesFilter.java:247)
at net.sourceforge.stripes.controller.DynamicMappingFilter.doFilter(DynamicMappingFilter.java:418)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.displaytag.filter.ResponseOverrideFilter.doFilter(ResponseOverrideFilter.java:125)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.vmware.loginsight.web.utilities.UTF8EncodingFilter.doFilter(UTF8EncodingFilter.java:24)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:563)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:394)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:861)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:606)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
at java.lang.Thread.run(Unknown Source)
The binding user validates connectivity to the default domain and is also used to validate a user/group being added to Log Insight. I assume after the bind you added a group to Log Insight? Then a user in the group attempted to log in and it failed? Is the group @corp.emc.com or @emc.com? Same with the user? Also can you generate a support bundle and upload per: http://kb.vmware.com/kb/1008525 (no need for SR just create a folder called ildus)
I think I'm seeing similar issues.
Bind user connects to prefix.domainname.suffix.
User's UPN is MyFirstName.MyLastName@DomainNameNewSuffixtoMatchMailAddress.com
Seems are using Office 365 and AD Federated Services so the "DomainNameNewSuffixtoMatchMailAddress" is a unmanaged domain. My assumption is that Log Insight is barfing @ the fact the domain the user account resides in has a different UPN domain suffix than the domain specified.
A KB should be posted on this soon. To authenticate in this configuration use the format:
<domain>\<username>@<upn>
Here you go: http://kb.vmware.com/kb/2069086
Hey Ildus - I believe your issue is resolved now. Could you mark this question as answered?