[Freeipa-users] AD Cross Realm Trust + AIX
Hi All, can I ask you for some advice? My setup is: - updated RHEL7 as IPA server (UX.EXAMPLE.COM) in trust with Active Directory 2008R2 domain (EXAMPLE.COM) - AIX 7 as IPA client I'm using compat tree for connecting AIX as client. A lot of things work correctly: # /usr/krb5/bin/kinit leszek Password for ad_u...@example.com: # /usr/krb5/bin/klist Ticket cache: FILE:/var/krb5/security/creds/krb5cc_0 Default principal: ad_u...@example.com Valid starting ExpiresService principal 02/12/15 15:46:23 02/13/15 01:46:31 krbtgt/example@example.com Renew until 02/13/15 01:46:23 # lsldap -a passwd ad_u...@example.com dn: uid=ad_u...@example.com,cn=users,cn=compat,dc=ux,dc=example,dc=com objectClass: posixAccount objectClass: extensibleObject objectClass: top gecos: ad_user cn: ad_user uidNumber: 1036620735 gidNumber: 1036620735 homeDirectory: /home/example.com/ad_user ipaNTSecurityIdentifier: S-1-5-21--X-XX uid: ad_u...@example.com # id ad_u...@example.com uid=1036620735(ad_u...@example.com) gid=1036620735(ad_u...@example.com) groups=1036620733(another_gr...@example.com) Here I found the first problem: # su - ad_u...@example.com 3004-614 Unable to change directory to . You are in /home/guest instead. $ id uid=1036620735(ad_u...@example.com) gid=1036620735(ad_u...@example.com) groups=1036620733(another_gr...@example.com) The 3004-614 Unable to change directory to . appears after I added to /etc/methods.cfg: KRB5A: program = /usr/lib/security/KRB5A program_64 = /usr/lib/security/KRB5A_64 options = authonly LDAP: program = /usr/lib/security/LDAP program_64 =/usr/lib/security/LDAP64 Without these lines there is no error about change to home directory, su from root works smoothly and entered the user to the homedirectory. But now I can't ssh to the system, because I have no correct registry. - I made another test: if I can log in by just IPA user, ex. admin. There is no such problem: # id admin uid=3(admin) gid=3(admins) # su - admin -bash-3.2$ pwd /export/home/admin -bash-3.2$ id uid=3(admin) gid=3(admins) # ssh admin@localhost admin@localhost's password: *** * * * * * Welcome to AIX Version 7.1!* * * * * * Please see the README file in /usr/lpp/bos for information pertinent to* * this release of the AIX Operating System. * * * * * *** -bash-3.2$ id uid=3(admin) gid=3(admins) Any idea what is wrong? I have already changed the AIX max_logname from 8 to 40 characters. Maybe the @ character in login name is a problem? Thank you in advance. -- /lm -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] slight problem when integrating certmonger with dogtag on fedora 21
What is your reasoning for setting up your own CA configuration? Why not
just use either ipa-getcert or getcert -c IPA?
I am not yet familiar with the entire setup enough to give a good answer. I
assume that requires full freeIPA setup, which i don't really need.
I just wanted a simplistic dogtag ca instance + certmonger setup for
watching certs on various machines and checking if the requests get filled
in correctly, and then expanding on it once i get more familiar with other
workings of it. And i got stuck on certmonger.
2015-02-11 19:14 GMT+01:00 Rob Crittenden rcrit...@redhat.com:
marcin kowalski wrote:
|Edit: i acceditanlly forgot to send copy to the list, so resubmitting.
I tried this command :
getcert request -c dogtag-ipa -f /etc/pki/testcert -k /etc/pki/testkey
-N cn=mywebserver
i've setup the 'dogtag-ipa' ca in certmonger like so :
id=dogtag-ipa
ca_aka=Dogtag (IPA,renew,agent) (certmonger 0.76.8)
ca_is_default=0
ca_type=EXTERNAL
ca_external_helper=/usr/libexec/certmonger/dogtag-ipa-renew-agent-submit
-E https://fedora.box.net:8443/ca/ee/ca -A
https://fedora.box.net:8443/ca/agent/ca/ -n CN=BOX.NET http://BOX.NET
admin -d /var/lib/pki/pki-tomcat/alias/ -i /etc/ipa/ca.crt -v
Since i haven't fully figured out how to setup authentication for
certmonger yet, i've temporarily reused one from the dogtag's pki
instance. Hopefully it's not a fatal mistake on my end.
What is your reasoning for setting up your own CA configuration? Why not
just use either ipa-getcert or getcert -c IPA?
rob
From the certmonger logs i get :
lut 11 09:52:19 fedora.box.net http://fedora.box.net
dogtag-ipa-renew-agent-submit[2887]: GET
https://fedora.box.net:8443/ca/ee/ca/profileSubmit?profileId=caServerCertcert_request_type=pkcs10cert_request=-BEGIN+NEW+CERTIFICATE+REQUEST-%0AMIICyTCCAbECAQAwFjEUMBIGA1UEAxMLbXl3ZWJzZXJ2ZXIwggEiMA0GCSqGSIb3%0ADQEBAQUAA4IBDwAwggEKAoIBAQDLZKK8dUqmiY2YAS2LrNE9DsB7QVhuATEcXkrc%0AB121jafN9BMyNSGQjWlpb15P4xqaXHrplQl60d4sSZA1d4GAxoywDUvoUA7R%2FrJ7%0AVcFyA7R5mRzK%2BfNUg%2FdLqTrnWM6GC1ecYwUwAmI%2FOFa5OomQczdGoV1ippguR2Un%0ArCCdXImZtni845FI1Wx745GP4mH2od7otSqGeLiQR9I6RLdrcs%2FC%2FWhWqPgUmyxp%0AEb%2BFS%2FAGPXG1nE2eT64z2OLQLJWfOT1uYRClsrQ9Bw96Cv20KPupEr4BPwfX%2BQzs%0AR7p9E%2BW1TuQhqX2NrWl4V%2F0tqc0omXGQZx62jCZM0m%2B2eoYJAgMBAAGgbjArBgkq%0AhkiG9w0BCRQxHh4cADIAMAAxADUAMAAyADEAMQAwADgANQAyADEAODA%2FBgkqhkiG%0A9w0BCQ4xMjAwMAwGA1UdEwEB%2FwQCMAAwIAYDVR0OAQEABBYEFEEoeB59tZYgOLSg%0AHV3fzBtlQCiaMA0GCSqGSIb3DQEBCwUAA4IBAQCpc3v8wp6csgKN3H8TfXe5Ay5h%0ATTqKyN2iLQKurTlTbwv%2FhZsE3ketuSfEOCJpE7Z58jlLB7VlMl6Uyl2MrOmC7Ro5%0Ai13LpVvVd%2FLsCedhM%2BTlYPtsk68DVcf1XKZARH6MIRmiDWSr0gajeP6bZK8znQ
!
K%2B%0A6O7
LaHKv1HaVcjxTZ%2Fdep3OF7aYtsz5tnyoaP1D2CI2WRRGnwjX4bBmr%2FQIZe7ba%0AOQt1yznFPjonEwVaOg3wkx0uaxdkyMz3MZC8nJxYCvBnNgV72tbA6As93laQaTQ2%0A24HhzdEWnJ019W72qJdTDpPg4DtloU0W%2BJYiIIpCfQIn1%2FjJLOnJcWiGPDDd%0A-END+NEW+CERTIFICATE+REQUEST-%0Axml=true
lut 11 09:52:19 fedora.box.net http://fedora.box.net
dogtag-ipa-renew-agent-submit[2887]: ?xml version=1.0
encoding=UTF-8
standalone=no?XMLResponseStatus2/StatusErrorRequest Deferred
- {0}/ErrorRequestId 49/RequestId/XMLResponse
And the request #49 is placed in Dogtag's CA Agent services, and can be
acknowledged/rejected correctly. It's just that certmonger is stuck and
doesn't notice the successful delivery.
Machine is in isolated network, so there is probably no issue wrt using
box.net http://box.net as test domain.|
2015-02-10 18:40 GMT+01:00 Dmitri Pal d...@redhat.com
mailto:d...@redhat.com:
On 02/10/2015 12:35 PM, marcin kowalski wrote:
Hi all, i'm getting dogtag figured out slowly, and i noticed one
odd thing.
I've setup certmonger to request an arbitrary certificate through
dogtag, and while the request seems to go into the dogtag system,
certmonger acts as if communication with the CA failed. The
certificate is considered in need of user attention because the
process got stuck.
Request ID ‘20150210125814’:
status: NEED_GUIDANCE
stuck: yes
key pair storage: type=FILE,location=’/etc/pki/testkey’
certificate: type=FILE,location=’/etc/pki/testcert’
CA: dogtag-ipa
issuer:
subject:
expires: unknown
pre-save command:
post-save command:
track: yes
auto-renew: yes
[root@fedora pki]# systemctl status -l certmonger
(….)
lut 10 13:57:04 fedora.box.net http://fedora.box.net
certmonger[7845]: Request for certificate to be stored in file
“/etc/pki/testcert” rejected by CA.
The request is present in dogtag and is valid, can be
accepted/rejected, etc. Even though certmonger never notices that.
I wonder if there is some obvious mistake in my setup, or perhaps
there is known bug in interaction of both components on F21 (i'm
using only standard repositories).
When i
Re: [Freeipa-users] ad relation with winsync
The is is treated as the ultimate source so adds should go only from AD to IPA but you need the modify to work both ways otherwise your account state will get out of sync. Whatever is required by docs is the minimal privilege you need to have to sync users. However did you consider trust? It us a two way trust but it acts as a one way trust. I know, but my customer don't want a two-way trust, whatever it means: - it fear some security concern with a two-way. - if he migrates its AD into new version or new topology, he fears to encounter some migration path issue So it has been decided to go the winsync way. btw, I manage to make my one way replication working, with less privileges, following http://directory.fedoraproject.org/docs/389ds/howto/howto-windowssync.html#creating-ad-user-with-replication-rights Thank you Nicolas -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] ad relation with winsync
On Thu, 12 Feb 2015, Nicolas Zin wrote: The is is treated as the ultimate source so adds should go only from AD to IPA but you need the modify to work both ways otherwise your account state will get out of sync. Whatever is required by docs is the minimal privilege you need to have to sync users. However did you consider trust? It us a two way trust but it acts as a one way trust. I know, but my customer don't want a two-way trust, whatever it means: - it fear some security concern with a two-way. We've been through this multiple times, check freeipa-users@ archives for arguments for and against. - if he migrates its AD into new version or new topology, he fears to encounter some migration path issue Cross-forest trust is the standard feature of AD, we foresee no migration path issues and it works with everything from Windows Server 2003 to Windows Server 2012R2 (though Red Hat only supports cross-forest trust starting with Windows Server 2008 onwards but this is mostly because 2003 is already out of support by Microsoft). So it has been decided to go the winsync way. btw, I manage to make my one way replication working, with less privileges, following http://directory.fedoraproject.org/docs/389ds/howto/howto-windowssync.html#creating-ad-user-with-replication-rights -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Where and how are passwords stored?
On 02/12/2015 08:20 AM, Dmitri Pal wrote:
On 02/12/2015 01:25 AM, Michael Lasevich wrote:
Ok, after a few awkward questions from an auditor, I am starting to face the
uncomfortable truth that my understanding about how FreeIPA works is a lot
fuzzier than I would like.
Specifically, the question I could not answer - where are the passwords
stored and how are they encrypted? My understanding is that all
authentication is handled by Kerberos server, which stores its data in LDAP -
but where and how is a bit of a mystery to me. Any way to dump out the
password hashes?
Passwords are stored in LDAP in two different attributes per entry. One with
LDAP password hash and another is Kerberos password hash allowing
authentication either with Kerebros or LDAP. Both follow best practices in
terms of using hash algorithms. The attributes themselves are protected by the
access control instructions (ACI) so only a super priviledged admin or user
himself can interact with this attribute. During normal operations it is not
fetched and read. The core of the DS processes it behind the closed doors so
it
is possible to reset but not to read.
This is how LDAP works and not different from any modern directory server.
Right. To prove Dmitri's point, see the 2 LDAP searches for all user attributes
containing key material (samba* are used when trusts are enabled).
First search as FreeIPA admin user:
# ldapsearch -Y GSSAPI -b
'uid=admin,cn=users,cn=accounts,dc=mkosek-f21,dc=test' uid userpassword
krbprincipalkey sambalmpassword sambantpassword
SASL/GSSAPI authentication started
SASL username: ad...@mkosek-f21.test
SASL SSF: 56
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base uid=admin,cn=users,cn=accounts,dc=mkosek-f21,dc=test with scope subtree
# filter: (objectclass=*)
# requesting: uid userpassword krbprincipalkey sambalmpassword sambantpassword
#
# admin, users, accounts, mkosek-f21.test
dn: uid=admin,cn=users,cn=accounts,dc=mkosek-f21,dc=test
uid: admin
# search result
search: 4
result: 0 Success
# numResponses: 2
# numEntries: 1
Second search with Directory Manager (god-like LDAP user):
# ldapsearch -D cn=Directory Manager -x -w kokos123 -b
'uid=admin,cn=users,cn=accounts,dc=mkosek-f21,dc=test' uid userpassword
krbprincipalkey sambalmpassword sambantpassword
# extended LDIF
#
# LDAPv3
# base uid=admin,cn=users,cn=accounts,dc=mkosek-f21,dc=test with scope subtree
# filter: (objectclass=*)
# requesting: uid userpassword krbprincipalkey sambalmpassword sambantpassword
#
# admin, users, accounts, mkosek-f21.test
dn: uid=admin,cn=users,cn=accounts,dc=mkosek-f21,dc=test
uid: admin
userpassword:: e1NTSEF9dHZEaUZ4ejJTUkRBLzh1NUZSSGVIT2N4WkZMci9OYktQNHNLNWc9PQ=
=
krbprincipalkey:: MIIBnKADAgEBoQMCAQGiAwIBAaMDAgEBpIIBhDCCAYAwaKAbMBmgAwIBBKES
BBA/WWlaNF0nOG80QDFaPWhYoUkwR6ADAgESoUAEPiAAxQsFjSPBOpCollrI8ex+lVnTg8GrZV6nl
baP3pZYoBtGVeQ3cBtYbl3usq9o+RIZfnNX2P8YZNlVmnjXMFigGzAZoAMCAQShEgQQL21HRSB6Pn
ZdQXpeYl5sQqE5MDegAwIBEaEwBC4QANB2xAVgnL2o3n3u+KkFHaEcije2vOdRcGmtZlhdsRHsCbn
y4/tydusWjrRxMGCgGzAZoAMCAQShEgQQUkckOF1SayxramRTWnkwUqFBMD+gAwIBEKE4BDYYAEo3
1vjbSStevF5QcY7WDc1RwFZ6paLp3WTAFATJSej0r+M8fVeNDgKb4CZHRKsNu9cMmdUwWKAbMBmgA
wIBBKESBBBCU1xDYmpxeHs6PGIkPi8voTkwN6ADAgEXoTAELhAATVwH6hkkO45W/Vmj0phXiDQe8j
Eq11TRGiRHsYKUFtp/3lh89/gp5OuhIyo=
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
# echo 'e1NTSEF9dHZEaUZ4ejJTUkRBLzh1NUZSSGVIT2N4WkZMci9OYktQNHNLNWc9PQ==' |
base64 --decode
{SSHA}tvDiFxz2SRDA/8u5FRHeHOcxZFLr/NbKP4sK5g==
Martin
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] slight problem when integrating certmonger with dogtag on fedora 21
On 02/12/2015 03:46 AM, marcin kowalski wrote:
What is your reasoning for setting up your own CA configuration? Why not
just use either ipa-getcert or getcert -c IPA?
I am not yet familiar with the entire setup enough to give a good
answer. I assume that requires full freeIPA setup, which i don't
really need.
I just wanted a simplistic dogtag ca instance + certmonger setup for
watching certs on various machines and checking if the requests get
filled in correctly, and then expanding on it once i get more familiar
with other workings of it. And i got stuck on certmonger.
I do not think certmonger is currently supported with pure Dogtag
without the IPA. There are some parts of it present but it might not
work end to end.
IN case of IPA certmonger uses kerberos to authenticate to server and
fetch the certs. Without IPA you have to deal with the pure cert base
setup which we have not had a priority complete.
2015-02-11 19:14 GMT+01:00 Rob Crittenden rcrit...@redhat.com
mailto:rcrit...@redhat.com:
marcin kowalski wrote:
|Edit: i acceditanlly forgot to send copy to the list, so
resubmitting.
I tried this command :
getcert request -c dogtag-ipa -f /etc/pki/testcert -k
/etc/pki/testkey
-N cn=mywebserver
i've setup the 'dogtag-ipa' ca in certmonger like so :
id=dogtag-ipa
ca_aka=Dogtag (IPA,renew,agent) (certmonger 0.76.8)
ca_is_default=0
ca_type=EXTERNAL
ca_external_helper=/usr/libexec/certmonger/dogtag-ipa-renew-agent-submit
-E https://fedora.box.net:8443/ca/ee/ca -A
https://fedora.box.net:8443/ca/agent/ca/ -n CN=BOX.NET
http://BOX.NET http://BOX.NET
admin -d /var/lib/pki/pki-tomcat/alias/ -i /etc/ipa/ca.crt -v
Since i haven't fully figured out how to setup authentication for
certmonger yet, i've temporarily reused one from the dogtag's pki
instance. Hopefully it's not a fatal mistake on my end.
What is your reasoning for setting up your own CA configuration?
Why not
just use either ipa-getcert or getcert -c IPA?
rob
From the certmonger logs i get :
lut 11 09:52:19 fedora.box.net http://fedora.box.net
http://fedora.box.net
dogtag-ipa-renew-agent-submit[2887]: GET
https://fedora.box.net:8443/ca/ee/ca/profileSubmit?profileId=caServerCertcert_request_type=pkcs10cert_request=-BEGIN+NEW+CERTIFICATE+REQUEST-%0AMIICyTCCAbECAQAwFjEUMBIGA1UEAxMLbXl3ZWJzZXJ2ZXIwggEiMA0GCSqGSIb3%0ADQEBAQUAA4IBDwAwggEKAoIBAQDLZKK8dUqmiY2YAS2LrNE9DsB7QVhuATEcXkrc%0AB121jafN9BMyNSGQjWlpb15P4xqaXHrplQl60d4sSZA1d4GAxoywDUvoUA7R%2FrJ7%0AVcFyA7R5mRzK%2BfNUg%2FdLqTrnWM6GC1ecYwUwAmI%2FOFa5OomQczdGoV1ippguR2Un%0ArCCdXImZtni845FI1Wx745GP4mH2od7otSqGeLiQR9I6RLdrcs%2FC%2FWhWqPgUmyxp%0AEb%2BFS%2FAGPXG1nE2eT64z2OLQLJWfOT1uYRClsrQ9Bw96Cv20KPupEr4BPwfX%2BQzs%0AR7p9E%2BW1TuQhqX2NrWl4V%2F0tqc0omXGQZx62jCZM0m%2B2eoYJAgMBAAGgbjArBgkq%0AhkiG9w0BCRQxHh4cADIAMAAxADUAMAAyADEAMQAwADgANQAyADEAODA%2FBgkqhkiG%0A9w0BCQ4xMjAwMAwGA1UdEwEB%2FwQCMAAwIAYDVR0OAQEABBYEFEEoeB59tZYgOLSg%0AHV3fzBtlQCiaMA0GCSqGSIb3DQEBCwUAA4IBAQCpc3v8wp6csgKN3H8TfXe5Ay5h%0ATTqKyN2iLQKurTlTbwv%2FhZsE3ketuSfEOCJpE7Z58jlLB7VlMl6Uyl2MrOmC7Ro5%0Ai13LpVvVd%2FLsCedhM%2BTlYPtsk68DVcf1XKZARH6MIRmiDWSr0gajeP6bZK8znQ!
K%2B%0A6O7
LaHKv1HaVcjxTZ%2Fdep3OF7aYtsz5tnyoaP1D2CI2WRRGnwjX4bBmr%2FQIZe7ba%0AOQt1yznFPjonEwVaOg3wkx0uaxdkyMz3MZC8nJxYCvBnNgV72tbA6As93laQaTQ2%0A24HhzdEWnJ019W72qJdTDpPg4DtloU0W%2BJYiIIpCfQIn1%2FjJLOnJcWiGPDDd%0A-END+NEW+CERTIFICATE+REQUEST-%0Axml=true
lut 11 09:52:19 fedora.box.net http://fedora.box.net
http://fedora.box.net
dogtag-ipa-renew-agent-submit[2887]: ?xml version=1.0
encoding=UTF-8
standalone=no?XMLResponseStatus2/StatusErrorRequest
Deferred
- {0}/ErrorRequestId 49/RequestId/XMLResponse
And the request #49 is placed in Dogtag's CA Agent services, and
can be
acknowledged/rejected correctly. It's just that certmonger is
stuck and
doesn't notice the successful delivery.
Machine is in isolated network, so there is probably no issue
wrt using
box.net http://box.net http://box.net as test domain.|
2015-02-10 18:40 GMT+01:00 Dmitri Pal d...@redhat.com
mailto:d...@redhat.com
mailto:d...@redhat.com mailto:d...@redhat.com:
On 02/10/2015 12:35 PM, marcin kowalski wrote:
Hi all, i'm getting dogtag figured out slowly, and i
noticed one
odd thing.
I've setup certmonger to request an arbitrary certificate
through
dogtag, and while the request seems to go into the dogtag
system,
certmonger acts as if communication with the CA failed. The
certificate is considered in need of user attention because the
process got stuck.
Request ID ‘20150210125814’:
status: NEED_GUIDANCE
stuck: yes
key pair storage:
Re: [Freeipa-users] Where and how are passwords stored?
On Thu, 2015-02-12 at 02:20 -0500, Dmitri Pal wrote: On 02/12/2015 01:25 AM, Michael Lasevich wrote: Ok, after a few awkward questions from an auditor, I am starting to face the uncomfortable truth that my understanding about how FreeIPA works is a lot fuzzier than I would like. Specifically, the question I could not answer - where are the passwords stored and how are they encrypted? My understanding is that all authentication is handled by Kerberos server, which stores its data in LDAP - but where and how is a bit of a mystery to me. Any way to dump out the password hashes? Passwords are stored in LDAP in two different attributes per entry. One with LDAP password hash and another is Kerberos password hash allowing authentication either with Kerebros or LDAP. Both follow best practices in terms of using hash algorithms. The attributes themselves are protected by the access control instructions (ACI) so only a super priviledged admin or user himself can interact with this attribute. During normal operations it is not fetched and read. The core of the DS processes it behind the closed doors so it is possible to reset but not to read. This is how LDAP works and not different from any modern directory server. Keep in mind that the Kerberos keys are additionally encrypted with a master password, so reading the attribute alone is useless. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Where and how are passwords stored?
On 02/12/2015 09:05 AM, Brad House wrote: On 02/12/2015 10:48 AM, Simo Sorce wrote: On Thu, 2015-02-12 at 07:38 -0800, Michael Lasevich wrote: Thank you, this is very helpful. I forgot about 'super admin', which is why I was not even seeing the values before. :-) How are the the values encrypted (or hashed?) It sounds like the password is stored in two fields(I am leaving samba out for now) - userpassword andkerberos principle key. Is userpassword a hash? Yes. Of so, what kind? Configurable, by default salted sha256 IIRC. Out of curiousity, where is this configurable? https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/User_Account_Management.html#User_Account_Management-Managing_the_Password_Policy This is the passwordStorageScheme attribute. Also, is it using it in conjunction with something like PBKDF2? https://fedorahosted.org/389/ticket/397 I'd love to know more info on this as we might want to increase the defaults ourselves. Thanks! -Brad -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Where and how are passwords stored?
On Thu, 2015-02-12 at 07:38 -0800, Michael Lasevich wrote: Thank you, this is very helpful. I forgot about 'super admin', which is why I was not even seeing the values before. :-) How are the the values encrypted (or hashed?) It sounds like the password is stored in two fields(I am leaving samba out for now) - userpassword andkerberos principle key. Is userpassword a hash? Yes. Of so, what kind? Configurable, by default salted sha256 IIRC. KerberosPrincipleKey you mention is encrypted with Kerberos master key - is the plaintext of password encrypted or is it a hash that is encrypted? All keys are hashes, they are stored into a asn.1 encoded structure that is then encrypted with the master key. What encryption and or hashing used for that? It depends on the supported keys. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Where and how are passwords stored?
On 2/12/15 7:48 AM, Rich Megginson wrote: On 02/12/2015 08:38 AM, Michael Lasevich wrote: Thank you, this is very helpful. I forgot about 'super admin', which is why I was not even seeing the values before. :-) How are the the values encrypted (or hashed?) It sounds like the password is stored in two fields(I am leaving samba out for now) - userpassword andkerberos principle key. Is userpassword a hash? Of so, what kind? Salted SHA 140 by default. You can crank this all the way up to Salted SHA 512. Where would you change it to get sha512?? ~J -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Where and how are passwords stored?
Thank you, this is very helpful. I forgot about 'super admin', which is why I was not even seeing the values before. :-) How are the the values encrypted (or hashed?) It sounds like the password is stored in two fields(I am leaving samba out for now) - userpassword andkerberos principle key. Is userpassword a hash? Of so, what kind? KerberosPrincipleKey you mention is encrypted with Kerberos master key - is the plaintext of password encrypted or is it a hash that is encrypted? What encryption and or hashing used for that? Thank you, -M On Feb 12, 2015 5:04 AM, Simo Sorce s...@redhat.com wrote: On Thu, 2015-02-12 at 02:20 -0500, Dmitri Pal wrote: On 02/12/2015 01:25 AM, Michael Lasevich wrote: Ok, after a few awkward questions from an auditor, I am starting to face the uncomfortable truth that my understanding about how FreeIPA works is a lot fuzzier than I would like. Specifically, the question I could not answer - where are the passwords stored and how are they encrypted? My understanding is that all authentication is handled by Kerberos server, which stores its data in LDAP - but where and how is a bit of a mystery to me. Any way to dump out the password hashes? Passwords are stored in LDAP in two different attributes per entry. One with LDAP password hash and another is Kerberos password hash allowing authentication either with Kerebros or LDAP. Both follow best practices in terms of using hash algorithms. The attributes themselves are protected by the access control instructions (ACI) so only a super priviledged admin or user himself can interact with this attribute. During normal operations it is not fetched and read. The core of the DS processes it behind the closed doors so it is possible to reset but not to read. This is how LDAP works and not different from any modern directory server. Keep in mind that the Kerberos keys are additionally encrypted with a master password, so reading the attribute alone is useless. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Where and how are passwords stored?
On 02/12/2015 08:38 AM, Michael Lasevich wrote: Thank you, this is very helpful. I forgot about 'super admin', which is why I was not even seeing the values before. :-) How are the the values encrypted (or hashed?) It sounds like the password is stored in two fields(I am leaving samba out for now) - userpassword andkerberos principle key. Is userpassword a hash? Of so, what kind? Salted SHA 140 by default. You can crank this all the way up to Salted SHA 512. KerberosPrincipleKey you mention is encrypted with Kerberos master key - is the plaintext of password encrypted or is it a hash that is encrypted? What encryption and or hashing used for that? Thank you, -M On Feb 12, 2015 5:04 AM, Simo Sorce s...@redhat.com mailto:s...@redhat.com wrote: On Thu, 2015-02-12 at 02:20 -0500, Dmitri Pal wrote: On 02/12/2015 01:25 AM, Michael Lasevich wrote: Ok, after a few awkward questions from an auditor, I am starting to face the uncomfortable truth that my understanding about how FreeIPA works is a lot fuzzier than I would like. Specifically, the question I could not answer - where are the passwords stored and how are they encrypted? My understanding is that all authentication is handled by Kerberos server, which stores its data in LDAP - but where and how is a bit of a mystery to me. Any way to dump out the password hashes? Passwords are stored in LDAP in two different attributes per entry. One with LDAP password hash and another is Kerberos password hash allowing authentication either with Kerebros or LDAP. Both follow best practices in terms of using hash algorithms. The attributes themselves are protected by the access control instructions (ACI) so only a super priviledged admin or user himself can interact with this attribute. During normal operations it is not fetched and read. The core of the DS processes it behind the closed doors so it is possible to reset but not to read. This is how LDAP works and not different from any modern directory server. Keep in mind that the Kerberos keys are additionally encrypted with a master password, so reading the attribute alone is useless. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Where and how are passwords stored?
On 02/12/2015 10:48 AM, Simo Sorce wrote: On Thu, 2015-02-12 at 07:38 -0800, Michael Lasevich wrote: Thank you, this is very helpful. I forgot about 'super admin', which is why I was not even seeing the values before. :-) How are the the values encrypted (or hashed?) It sounds like the password is stored in two fields(I am leaving samba out for now) - userpassword andkerberos principle key. Is userpassword a hash? Yes. Of so, what kind? Configurable, by default salted sha256 IIRC. Out of curiousity, where is this configurable? Also, is it using it in conjunction with something like PBKDF2? I'd love to know more info on this as we might want to increase the defaults ourselves. Thanks! -Brad -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
