Hi Ben, Is there any useful information you could share on your failure that may help with debugging or finding an alternative? ... View more

hello Neerraj, i'm looking for integrating LDAP server with hortonworks sandbox Ambari (HDP 2.5) and ambari-server --version 2.4.0.0-1225 i have tried twice to run "ambari-server setup-ldap" and "ambari-server sync-ldap –all" twice, but i'm keeping having error 403 at the beginning of LDAP Sync. when this error come up, i'm not able anymore to logging into Ambari UI with my Ambari credentials (admin/password). even after reseting my password with "ambari-admin-password-reset". but what i've observed so far is that i could in logging with "maria_dev/maria_dev" credential and also with some new user i have added during LDAP setup server. i was wondering if this could be a password migration tools that is doing the wrong password migration? i have checked the user "admin" in my LDAP database, and i can observe that it's not encrypted in the same way as user like maria_dev or raj_ops!! (see below): can this cause trouble during my ambari-server and LDAP synchronization? or it is due to my ambari-server LDAP setup settings? ==> MARIA_DEV INFORMATIONS [root@sandbox ~]# ldapsearch -x cn=maria_dev -b dc=hortonworks,dc=com # extended LDIF # # LDAPv3 # base with scope subtree # filter: cn=maria_dev # requesting: ALL # # maria_dev, People, hortonworks.com dn: uid=maria_dev,ou=People,dc=hortonworks,dc=com uid: maria_dev cn: maria_dev sn: maria_dev mail: maria_dev@hortonworks.com objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount objectClass: top objectClass: shadowAccount userPassword:: e2NyeXB0fSQ2JC94YTFDb0dTMnAvOC4yRCQ3MDkuL1pYRHpnV01vVGIzeWdnNnd HNUNuM2ZXck82QTBzUGhOZzVFZEpodjF2LmRTQnBEelJUMHpPaFBUdmxZSzhGU3NVZEppS1M2QUFo OXpqLld1MQ== shadowLastChange: 17099 shadowMin: 0 shadowMax: 99999 shadowWarning: 7 loginShell: /bin/bash uidNumber: 1023 gidNumber: 1023 homeDirectory: /home/maria_dev # maria_dev, Group, hortonworks.com dn: cn=maria_dev,ou=Group,dc=hortonworks,dc=com objectClass: posixGroup objectClass: top cn: maria_dev userPassword:: e2NyeXB0fXg= gidNumber: 1023 =======> ADMIN INFORMATION: [root@sandbox ~]# ldapsearch -x cn=admin -b dc=hortonworks,dc=com # extended LDIF # # LDAPv3 # base with scope subtree # filter: cn=admin # requesting: ALL # # admin, People, hortonworks.com dn: uid=admin,ou=People,dc=hortonworks,dc=com uid: admin cn: admin sn: admin mail: admin@hortonworks.com objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount objectClass: top objectClass: shadowAccount userPassword:: e2NyeXB0fSEh shadowLastChange: 17099 shadowMin: 0 shadowMax: 99999 shadowWarning: 7 loginShell: /bin/bash uidNumber: 1005 gidNumber: 1005 homeDirectory: /home/admin # admin, Group, hortonworks.com dn: cn=admin,ou=Group,dc=hortonworks,dc=com objectClass: posixGroup objectClass: top cn: admin userPassword:: e2NyeXB0fXg= gidNumber: 1005 # search result search: 2 result: 0 Success thanks a lot for your help. regards. sidoine. ... View more

Yes! GRANT ALL is needed! mysql> create database oozie; Query OK, 1 row affected (0.00 sec) mysql> grant all privileges on oozie.* to 'oozie'@'localhost' identified by 'oozie'; Query OK, 0 rows affected (0.00 sec) mysql> grant all privileges on oozie.* to 'oozie'@'%' identified by 'oozie'; Query OK, 0 rows affected (0.00 sec) mysql> exit ... View more

Why are the dates in the log from 7/24/2014? Is this an old issue that hasn't been solved and you are reposting it, or is your clock incorrect? If your clock is incorrect, than you will have Kerberos issues since time is a big factor in determining the validity of the credentials. The clocks on the hosts need to be within 5 minutes of the host that contains the KDC, else bad things will happen. If this is an old issue and you are using HDP 2.1, then I assume you are using Ambari 1.6.x. In this version of Ambari, you must have set up Kerberos manually. Since there is a lot of room for error, you should go back and make sure you didn't miss a step or incorrect create a keytab file. Unless you create the keytab file for a particular principal using kadmin.local, the password for the account will get regenerated. This will cause issues if you create multiple keytab files for the same principal - the 2nd time you generate a keytab file, the 1st keytab file will become obsolete; the 3rd time you generate a keytab file, the 2nd keytab file will become obsolete, etc... Also, make sure all of the configs were set properly. By incorrectly setting a principal name or keytab file location, one or more services will fail to authenticate. Finally, check the ACLs on the keytab files to make sure that the relevant service(s) can read them. If a service is running as the local hdfs user, but the keytab file is only readable by root, than the service cannot read the keytab file and authentication will fail. ... View more

Thank you for your Micorsoft contributions on HCC @Cindy Gross ... View more

Hi, We have similar issue. After security update were applied, started getting nio:720 - javax.net.ssl.SSLException: Any solution? Appreciate any help/support in advance ... View more

Perfect solution, it works ... View more