Member since
10-15-2014
27
Posts
1
Kudos Received
0
Solutions
04-24-2020
02:30 PM
@bgooley In CDH 6.3.x, this appears to have changed and the "https.py" file is slightly different now. It accepts the cipher_list as a configuration item. The way we secured Port 900 is by doing these steps: 1) Check to see if RC4 (and other weak ciphers) are open on Port 9000: openssl s_client -cipher RC4 -connect <server>:9000 -msg 2) Edit the "/etc/cloudera-scm-agent/config.ini" file 3) Under the "[Security]" section of the config.ini file, we added these lines: # Custom Cipher List to close vulnerabilities for port 9000 cipher_list=HIGH:!DSS:!DH:!ADH:!DES:!3DES:!SHA1:!RC4:!aNULL:!eNULL:!EXPORT:!SSLv2:!SSLv3:!TLSv1 4) Restart the Cloudera CM-Agent: sudo service cloudera-scm-agent restart 5) Wait a minute or so and then rerun the OpenSSL command and RC4 (and other weak ciphers, if you test them) are closed: openssl s_client -cipher RC4 -connect <server>:9000 -msg It would be great if Cloudera could add this to their documentation on how to add this additional security to the CM Agent.
... View more
08-08-2018
08:27 AM
" UTC timezone conversion issue going on with only Parquet backed tables." > how do Cloudera Customers deal with this issue? I fear the first solution is to have all your servers use the same (UTC) timezone. We also have this flag setconvert_legacy_hive_parquet_utc_timestamps=true and hope to get rid of it once we move everything to UTC.
... View more
01-16-2018
09:35 AM
hi BrettM , Did you find a solution for this ? I am trying to connect DB2 on Z/OS using Sqoop .
... View more
07-30-2015
10:13 AM
1 Kudo
Add [desktop] [[session]] ttl=900 to the CM Hue safety Valve: *Note:* To override a value in Cloudera Manager, you need to enter verbatim each mini section from below into the Hue Safety Valve : Hue Service → Configuration → Service-Wide → Advanced → Hue Service Advanced Configuration Snippet (Safety Valve) for hue_safety_valve.ini http://gethue.com/how-to-configure-hue-in-your-hadoop-cluster/ Romain
... View more
02-11-2015
09:09 PM
1) How will this work when we want to change the existing AD domain in CDH v5.3 via CM?
Navigate to the Administration > Settings > Kerberos > "Kerberos Security Realm " setting and set it to the new REALM name. This will clear the collection of principal entries in the cloudera manager "SCM" database, but leaves the entries in AD. We suggest the entries in AD should be deleted as well.
2) What happens to the LDAP users currently setup in Hue? Will they automatically get wiped out?
Actually the users in hue are in a database locally and are mapped through the hue configuration against the target AD service, resolving the sAMAccountName attribute to the hue user and group db values. It should continue to work, make a backup of the hue database file (described in our docs) unless you configured the hue db against a production db server (like postgres, or mysql or oracle).
3) Is there another wizard-driven method to change the AD domain so we know the service principals get setup correctly?
Yes per above comments;
i.) stop cluster services (CDH and CM management services)
ii.) delete cluster kerberos principals from AD suffix you are in via AD administrative UI or pre-created ldapdelete script to remove entries (better to have AD admin remove them)
iii.) change the "Kerberos Security Realm" value from the CM > Administration > Settings > Kerberos > screen (this clears the CM db merged keytab and credentials tables)
iv.) We suggest also deleting the CM Kerberos Account Manager user and re-creating it, and assigning the add/delete/modify rights for user accoungs against the OU to agin based on our docs).
v.) At that point you would "Import Kerberos Account Manager Credentials" again for the new REALM.
vi.) navigate to Administration > Kerberos > Credentials (top of navigation) and click "generate credentials" and it should properly re-generate your CM credentials.
The actual AD entry for each cluster service principal is reflected in the servicePrincipalName entry in the form of [service]/[host.fqdn.name] and in the userPrincipalName entry in the form of [service]/[host.fqdn.name]@[AD.DOMAIN.AS.REALM]
We recommend you clear out the existing cluster principals. You will need to review either updating the CM user's entries userPrincipalName value if its not automatically done by AD, or delete and re-create the user and assign rights to the suffix to that new version of the CM user. The standing academic question is; does the AD service update all userPrincipalName entries to reflect the new domain name as the uppercase realm name? That would introduce a second possible scenario of editing the entries and trying to get CM to regenerate the credentials, but that has a lower rate of success. Its easier to clear and generate new than attempt to sync existing with the SCM db's credentials and merged keytab tables.
... View more