Re: [Freeipa-users] user keytab retrieval
hi rob, >> i'm a bit puzzled by the following: i want to retrieve a user keytab >> using ipa-getkeytab -r (since the keytab for the same user was already >> retrieved on another host). >> >> when doing so, i get >> >> Failed to parse result: Insufficient access rights >> >> however, i can get the keytab without the -r option. >> >> anyone care to explain what access rights are required (or why this >> error occurs)? > > Being able to retrieve an existing key means being able to read it which > isn't granted by default. ok, but why is a "regular" ipa-getkeytab no problem? > > It depends on how you want to grant this access: to this one user, to > all users, to groups, etc. i only need to get the user keytab on a few machines; i could probably scp it from one host to the other. but i assumed that ipa-getkeytab -r would do the same. > > The attribute you want is ipaProtectedOperation;read_keys but use it > very carefully because you are granting read access to keys. ok, i'll try to read a bit more about it first. stijn -- 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
[Freeipa-users] user keytab retrieval
hi all, (this is IPA 4.4.0-14.el7.centos.4) i'm a bit puzzled by the following: i want to retrieve a user keytab using ipa-getkeytab -r (since the keytab for the same user was already retrieved on another host). when doing so, i get Failed to parse result: Insufficient access rights however, i can get the keytab without the -r option. anyone care to explain what access rights are required (or why this error occurs)? many thanks, stijn -- 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
[Freeipa-users] group-add-member external "trusted domain object not found"
hi all, i'm trying to setup a one-sided trust with an AD, following https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/trust-groups.html the trust is setup and seems to work (i get IPA service token using kvno and an AD kerberos credential), "ipa trustdomain-find domain.name" reports that the domain is enabled (but for some reason dumps this info twice). however, when trying to add the "Domain Users", i get a 'trusted domain object not found' > # ipa group-add-member extgroup --external="NETBIOSNAME\Domain Users" > --users=a_valid_ad_user > Group name: extgroup > Description: some desc > Member of groups: intgroup > Failed members: > member user: a_valid_ad_user: no such entry > member group: NETBIOSNAME\Domain Users: trusted domain object not found > - > Number of members added 0 > - i also tried with "Domain us...@domain.name" any clues how to debug what is going wrong? many thanks, stijn -- 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] minimise impact compromised host
hi petr, i reread the links and some other info. it should indeed not be possible to abuse those. i thought i was once able to abuse these, but i've tried to reproduce what i did and failed (probably some ssh forwarding was mixed at that time). stijn On 11/16/2016 06:58 PM, Petr Spacek wrote: > On 16.11.2016 18:26, Stijn De Weirdt wrote: >> hi petr, >> >>>>>> this is a different question: what can we do such that compromised host >>>>>> can do a little as possible if the admin doesn't (yet) know the host is >>>>>> compromised. >>>>>> >>>>>> the default policy allows way too much. >>>>> >>>>> For any useful advice we need more details. >>>>> >>>>> What are the operations you want to disable? >>>> at the very least, "kvno userlogin" should fail (i.e. access to a host >>>> keytab shouldn't permit retrieval of arbitrary user token). >>> >>> I think that this is misunderstanding. >> i'll spend some more time rereading and getting a better understanding >> (again ;) >> >>> >>> "kvno userlogin" does not allow the attacker to do anything. The result of >>> kvno command is a service ticket for particular principal (user, host). >>> >>> The attacker can use this service ticket *for authentication to the >>> particular >>> principal* (user, host). >>> >>> So the only thing the attacker can do is to prove its identity to given >>> (user, >>> host). This exactly matches capabilities the attacker already has - the full >>> control over the host. >> hhmm, ok. is there a way to let e.g. klist show this? it now says >> 'userlogin@REALM' in the 'Service principal' column. for the (user,host) >> combo i expected to see a userlogin/fqdn@REALM, like other service tokens. >> >> anyway, clearly i'm missing something here. > > The important field is 'Default principal:' which is above the list of > tickets. It contains name of the principal "who you are". > > Rest of the list shows just service tickets which are used to authenticate you > to the services listed in the list. It just means that you tried to contact > them some time ago (or called kvno explicitly). > > Please go and read some articles about Kerberos protocol, e.g. the Wikipedia > article I linked below. It will explain a lot of things. > > Petr^2 Spacek > >> >> >> stijn >> >>> >>> Please see >>> https://en.wikipedia.org/wiki/Kerberos_(protocol)#Client_Service_Request >>> for further details on this. >>> >>> Does it explain the situation? >>> >>> Petr^2 Spacek >>> >>>> >>>> i'm assuming that retrieval of service tokens for another host is >>>> already not possible? (ie if you have keyatb of fqdn1, you shouldn't be >>>> able to retrieve a token for SERVICE/fqdn2@REALM). >>>> >>>> stijn >>>> >>>>> >>>>> Petr^2 Spacek >>>>> >>>>> >>>>>> >>>>>> how to clean it up once you know the host is compromised is the subject >>>>>> of the other thread. >>>>>> >>>>>> stijn >>>>>> >>>>>>> >>>>>>> In the case that the host is compromised/stolen/hijacked, you can >>>>>>> host-disable it to invalidate the keytab stored there but this does not >>>>>>> prevent anyone logged on that host to bruteforce/DOS user accounts by >>>>>>> trying to guess their Kerberos keys by repeated kinit. >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> > > -- 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] minimise impact compromised host
hi petr, this is a different question: what can we do such that compromised host can do a little as possible if the admin doesn't (yet) know the host is compromised. the default policy allows way too much. >>> >>> For any useful advice we need more details. >>> >>> What are the operations you want to disable? >> at the very least, "kvno userlogin" should fail (i.e. access to a host >> keytab shouldn't permit retrieval of arbitrary user token). > > I think that this is misunderstanding. i'll spend some more time rereading and getting a better understanding (again ;) > > "kvno userlogin" does not allow the attacker to do anything. The result of > kvno command is a service ticket for particular principal (user, host). > > The attacker can use this service ticket *for authentication to the particular > principal* (user, host). > > So the only thing the attacker can do is to prove its identity to given (user, > host). This exactly matches capabilities the attacker already has - the full > control over the host. hhmm, ok. is there a way to let e.g. klist show this? it now says 'userlogin@REALM' in the 'Service principal' column. for the (user,host) combo i expected to see a userlogin/fqdn@REALM, like other service tokens. anyway, clearly i'm missing something here. stijn > > Please see > https://en.wikipedia.org/wiki/Kerberos_(protocol)#Client_Service_Request > for further details on this. > > Does it explain the situation? > > Petr^2 Spacek > >> >> i'm assuming that retrieval of service tokens for another host is >> already not possible? (ie if you have keyatb of fqdn1, you shouldn't be >> able to retrieve a token for SERVICE/fqdn2@REALM). >> >> stijn >> >>> >>> Petr^2 Spacek >>> >>> how to clean it up once you know the host is compromised is the subject of the other thread. stijn > > In the case that the host is compromised/stolen/hijacked, you can > host-disable it to invalidate the keytab stored there but this does not > prevent anyone logged on that host to bruteforce/DOS user accounts by > trying to guess their Kerberos keys by repeated kinit. > >>> >>> >> > > -- 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] minimise impact compromised host
>> this is a different question: what can we do such that compromised host >> can do a little as possible if the admin doesn't (yet) know the host is >> compromised. >> >> the default policy allows way too much. > > For any useful advice we need more details. > > What are the operations you want to disable? at the very least, "kvno userlogin" should fail (i.e. access to a host keytab shouldn't permit retrieval of arbitrary user token). i'm assuming that retrieval of service tokens for another host is already not possible? (ie if you have keyatb of fqdn1, you shouldn't be able to retrieve a token for SERVICE/fqdn2@REALM). stijn > > Petr^2 Spacek > > >> >> how to clean it up once you know the host is compromised is the subject >> of the other thread. >> >> stijn >> >>> >>> In the case that the host is compromised/stolen/hijacked, you can >>> host-disable it to invalidate the keytab stored there but this does not >>> prevent anyone logged on that host to bruteforce/DOS user accounts by >>> trying to guess their Kerberos keys by repeated kinit. >>> >> > > -- 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] minimise impact compromised host
hi martin, >>> we are looking how to configure whatever relevant policy to minimise the >>> impact of compromised IPA hosts (ie servers with a valid host keytab). >>> >>> in particular, it looks like it possible to retrieve any user token once >>> you have access to a valid host keytab. >>> >>> we're aware that the default IPA policies are wide open, but we are >>> looking how to limit this. for us, there's no need that a hostkeytab can >>> retrieve tokens for anything except the services on that host. >> >> What "token" do you have in mind? >> > We discussed this in another thread. this is a different question: what can we do such that compromised host can do a little as possible if the admin doesn't (yet) know the host is compromised. the default policy allows way too much. how to clean it up once you know the host is compromised is the subject of the other thread. stijn > > In the case that the host is compromised/stolen/hijacked, you can > host-disable it to invalidate the keytab stored there but this does not > prevent anyone logged on that host to bruteforce/DOS user accounts by > trying to guess their Kerberos keys by repeated kinit. > -- 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] minimise impact compromised host
>> we are looking how to configure whatever relevant policy to minimise the >> impact of compromised IPA hosts (ie servers with a valid host keytab). >> >> in particular, it looks like it possible to retrieve any user token once >> you have access to a valid host keytab. >> >> we're aware that the default IPA policies are wide open, but we are >> looking how to limit this. for us, there's no need that a hostkeytab can >> retrieve tokens for anything except the services on that host. > > What "token" do you have in mind? > service tokens, like HTTP/fqdn@REALM should work, but i expect in the following example that the kvno part fails kinit -kt /etc/krb5.keytab kvno a_valid_user stijn -- 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
[Freeipa-users] minimise impact compromised host
hi all, we are looking how to configure whatever relevant policy to minimise the impact of compromised IPA hosts (ie servers with a valid host keytab). in particular, it looks like it possible to retrieve any user token once you have access to a valid host keytab. we're aware that the default IPA policies are wide open, but we are looking how to limit this. for us, there's no need that a hostkeytab can retrieve tokens for anything except the services on that host. stijn -- 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] keytab for user
so the trick is to first login with the random password, it will prompt to renew it, and with a new password set, you can retrieve a usable keytab. stijn > > i'm trying to create a keytab for a user via FreeIPA > > user was added via ipa user-add --random; keytab retrieved using > ipa-getkeytab (using admin credentials) > > klist -k list shows a number of entries for same KVNO > > however, i cannot get any credentials using kinit -kt > > it always returns: > "kinit: Password has expired while getting initial credentials" > > ipa user-show gives >> Account disabled: False >> Password: True > ... >> Kerberos keys available: True > > what am i doing wrong? (i never used the original random password to > try to get initial credentials for this user; i don't even kept it ;) > > many thanks, > > stijn > -- 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
[Freeipa-users] keytab for user
hi all, i'm trying to create a keytab for a user via FreeIPA user was added via ipa user-add --random; keytab retrieved using ipa-getkeytab (using admin credentials) klist -k list shows a number of entries for same KVNO however, i cannot get any credentials using kinit -kt it always returns: "kinit: Password has expired while getting initial credentials" ipa user-show gives > Account disabled: False > Password: True ... > Kerberos keys available: True what am i doing wrong? (i never used the original random password to try to get initial credentials for this user; i don't even kept it ;) many thanks, stijn -- 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] using AD token to get freeipa token
hi simon, ok, that's pity. the problem we are trying to solve is teh following: we are going to setup a new krb5 realm with IPA and we would like to explore methods to have our users authenticate against this realm (well, the kinit otherusername@IPA part) using methods that existing/available for our users. i.e. we would really really like to avoid that our users have to create yet another password. the users currently are in AD, so we tought we could use the AD tokens to authenticate, avoiding passwords. maybe i should rephrase my original question a bit: what authentication schemes does kinit support (is there anything besides using a password), and if passwords are unavoidable, is it possible to use something like OTP with kinit and IPA (the user somehow gets the OTP, and can use that for kinit with an IPA controlled realm)? (maybe it is possible that the password verification step from IPA is handed over to AD somehow?). anyway, hints are welcome stijn On 07/09/2014 11:23 PM, Simo Sorce wrote: On Wed, 2014-07-09 at 18:38 +0200, Stijn De Weirdt wrote: hi all, we are investigating the possibility to use an existing and valid AD token to obtain a token from a realm under FreeIPA (3.3.3 from el7), without having to setup the full IPA AD cross realm trust. (in particular, to avoid that AD has to trust the IPA setup; and with the goal that we can minimise any required actions on the AD setup). what we would like to achieve is the following: kinit user@AD --- authenticate via AD password kinit otherusername@IPA -- no password required, authentication based on valid AD token so one can then eg ssh otherusern...@machine.under.ipa.control the user@AD to otherusername@IPA mapping is provided somewhere on the IPA server and is static. as far as i understood, this is (very?) different from actual trust relation where having the user@AD token is sufficient to do ssh otherusern...@machine.under.ipa.control. any hints are welcome! It's not possible*, sorry. Simo. * At the very theoretical level it would, but it would require extensive changes to the kerberos libraries on each client as well as changes to the KDC. Operationally unfeasible even if you had those code changes. -- 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] using AD token to get freeipa token
hi simon, ok, that's pity. the problem we are trying to solve is teh following: we are going to setup a new krb5 realm with IPA and we would like to explore methods to have our users authenticate against this realm (well, the kinit otherusername@IPA part) using methods that existing/available for our users. i.e. we would really really like to avoid that our users have to create yet another password. the users currently are in AD, so we tought we could use the AD tokens to authenticate, avoiding passwords. You can do this by establishing a trust between AD and IPA. but a trust goes way further then what we need from it (and then there are issues with the AD admins trusting us. any impact on AD is not really acceptable). i'd like to avoid it if possible (but i feel i'll have to read up on the topic so i properly understand the consequences) maybe i should rephrase my original question a bit: what authentication schemes does kinit support (is there anything besides using a password), and if passwords are unavoidable, is it possible to use something like OTP with kinit and IPA (the user somehow gets the OTP, and can use that for kinit with an IPA controlled realm)? (maybe it is possible that the password verification step from IPA is handed over to AD somehow?). In FreeIPA 4.0 we introduced support for 2FA and TOTP, it still requires a password, the OTP is only the second factor. ok, understood. Another option is to sync users and passwords from AD to IPA, we do not recommend this but it is possible. i'd rather not Finally there is a very hackish client configuration some people used where authentication happens against AD but everything else is going through IPA. I do not feel like recommending this. any more info on this? (how hackish is it? and what is meant with client configuration?) thanks for the input! stijn Simo. -- 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
[Freeipa-users] using AD token to get freeipa token
hi all, we are investigating the possibility to use an existing and valid AD token to obtain a token from a realm under FreeIPA (3.3.3 from el7), without having to setup the full IPA AD cross realm trust. (in particular, to avoid that AD has to trust the IPA setup; and with the goal that we can minimise any required actions on the AD setup). what we would like to achieve is the following: kinit user@AD --- authenticate via AD password kinit otherusername@IPA -- no password required, authentication based on valid AD token so one can then eg ssh otherusern...@machine.under.ipa.control the user@AD to otherusername@IPA mapping is provided somewhere on the IPA server and is static. as far as i understood, this is (very?) different from actual trust relation where having the user@AD token is sufficient to do ssh otherusern...@machine.under.ipa.control. any hints are welcome! stijn -- 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] change min and max lifetime of random password
hi all, IMO we should not treat the OTP we set for the host enrollment as a kerberos password. I would rather record a time of the creation and validity period when the password is set in two new attributes. The validity period should be optional and if not provided copied from a system wide policy that can be set by default to say 10 min. When we do authentication with OTP we should check whether we are already beyond the point when the OTP is valid and fail enrollment. When we validate and clear OTP we do not need to change these two attributes, they contain valuable info that might be queried later. i like this idea. full host password policy is probably overkill for an OTP that only makes sense once in the lifetime of the host (OTP here means not only is the password itself only valid once; the whole password authentication is only valid/usable once). btw, is it easy (as in API exists) to add new (site specific) attributes for a host? if so, i can already toy around with it for now. (storing the creation time in it and some cron job might suffice for now) stijn ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] writing IPA plugin
hi all, i'm trying to write my own FreeIPA plugin (for frontend cli usage), and so far so good, but i'm stuck on 2 issues: - is it possible to have the plugin use a dedicated or additional log file? i can manipulate the log manager, but maybe there's a proper API in freeipa for it; similar to the log_file_name in ipapython.admin.AdminTool classes - i want to exit the plugin on certain error conditions and want to exit with non-zero exitcode. how can this be done? many thanks, stijn ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] writing IPA plugin
hi rob, i'm trying to write my own FreeIPA plugin (for frontend cli usage), and so far so good, but i'm stuck on 2 issues: - is it possible to have the plugin use a dedicated or additional log file? i can manipulate the log manager, but maybe there's a proper API in freeipa for it; similar to the log_file_name in ipapython.admin.AdminTool classes - i want to exit the plugin on certain error conditions and want to exit with non-zero exitcode. how can this be done? Which side do you want to do the logging on, the server or client side? the client side The return value is controlled by the exception raised. There is an rval attribute defined in the exception. thanks! stijn rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] change min and max lifetime of random password
hi alexander, ity would be good anyway to have a script that checks all hosts that have not enrolled yet how old the issued password is (even after expiration). very useful to spot the state of ongoing deployments and to spot problems. how can one obtain the creation time of the password? fetch the timestamp from LDAP or is there a nice ipa API for it? Since host object is a Kerberos principal, it has krbLastSuccessfulAuth and krbLastPwdChange attributes. ipa host-show host.name --all --raw will give you their values. # ipa host-show `hostname` --all --raw |grep krbLast krbLastPwdChange: 20140213123016Z krbLastSuccessfulAuth: 20140325073031Z this does not seem to work on a host that has the random password set (or set a few times), but no keytab was created or other form of authentication: ipa host-show test.test --all --raw |grep -E 'krb|has_' has_password: True has_keytab: False krbExtraData: AAI3mDRTcm9vdC9hZG1pbkB krbPrincipalName: host/test.test@TEST objectClass: krbprincipalaux objectClass: krbprincipal (this is freeipa 3.3.3 on rhel7 beta) stijn ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] change min and max lifetime of random password
hi alexander, No real password is in the kickstart file, OTP will turn itself off automatically on enrollment and time has to be within the window of opportunity. but the password itself is still valid if the install failed and someone else tries to use it. Right. Nobody actually prevents you from running a cron job on the server side to lock down these passwords if they were not used up in a fixed amount of time. hence my request for password expiration. ity would be good anyway to have a script that checks all hosts that have not enrolled yet how old the issued password is (even after expiration). very useful to spot the state of ongoing deployments and to spot problems. how can one obtain the creation time of the password? fetch the timestamp from LDAP or is there a nice ipa API for it? it's good that you can't guess the password that easily (it's slightly better than a fixed string in the kickstart script), might be a good candidate if it was coupled with a short enough lifetime. (coupled with minimum lifetime as an offset, you might even schedule installations in the future). i don't understand what the ip adds to the password though. the ipa-client-install should fail if the ip/hostname doesn't match the data in freeipa for that host, right? (the only secret is in the timewindow that the admin scheduled, assume that the ipa-client-install enforces the ip/hostname) In a typical environment you have central control over those types of data associated with the spawned machines, like MAC addresses or IP addresses. If the password is including bits that are forced to the host by a central authority, it makes harder to get rogue clients to re-use the same template for other combinations of MAC/IP address. They would need to know exact IP or MAC address of the machine they want to impersonate. You can take other unique parameters into account. You need to think of what is truly unique to your clients but there still will be question of trust to the client who attempts to authenticate. This trust should be verified on multiple levels, a password to enroll the client is just one of them. as dmitry pointed out in previous mail, i was mistaken that IPA has tight coupling by default between hostname and IP (the DNS is optional). anyway, thanks again for the feedback. stijn ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] change min and max lifetime of random password
hi all, i'm trying to limit the minimum and maximum lifetime of passwords (in particular the random password when a host is added; but i guess this more general). (i'm using ipa 3.0 from el6 and also looking at 3.3 from rhel7 beta, but the relevant code seems the same or at least very similar) i'm currently adding the host first via the api and then setting the random password with host_mod like api.Command.host_add(u''+host) api.Command.host_mod(u''+host,random=True) (for some reason, this is what is needed on 3.0; anyway, that's not my issue) is there a way that i can change it easily somehow afterwards (preferred way) or can i create and use a custom pwpolicy class that sets my preferred defaults (min 1 minute, max 20 minutes); or do i monkeypatch the whole class (assuming that pwpolicy_add is called on the user side, not on the server side). all tips are welcome. many thanks, stijn ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] change min and max lifetime of random password
hi dmitri, The whole idea of the host passwords is to be added as a part of the provisioning workflow so it should be seconds anyways. We created a smart proxy for Foreman (provisioning system) to drive host creation. It just landed upstream (first version) last week. Any chance you can use or reuse some of the code from it in your provisioning workflows? i'll have a closer looks at the code, but the goal is the same. Also can you explain why the expiration time is needed? I can understand it being needed if the password is created ahead of time and then not used for a period of time but here it is really one flow. You can't predict how much it would be 2 sec or 10 seconds but is it really important to put a cap on it? yes. we mark hosts for (re)installation and if this does not get completed within certain time, something must have gone wrong. in the meanwhile, we want this security window closed (the OTP password would be in a kickstart file, which can't be protected that easily, because it still has to work as a kickstart file). 1 day max is way too much in this context. If this is desired the right feature would be to add couple attributes to the host entry: creation time and validity interval and set them when the password is created. But it is more than a quick fix. You a welcome to file and RFE and putt all the details in the ticket. ok, will do. stijn many thanks, stijn ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] change min and max lifetime of random password
hi rob, You can only specify password policy for User Groups, not host groups, so there is no way to do this currently. It also isn't that fine-grained. The minimum lifetime is 1 hour, the minimum of the maximum lifetime is 1 day. I don't see why support for Host Groups (and therefore Hosts) can't be added. I'm not 100% sure about the tuning for min/max lifetime but it should be possible. AFAIR we convert the values from seconds to hours and days. the values are converted and appear to get stored in seconds (looking at the code, maybe i misunderstand it). Can you file a ticket at https://fedorahosted.org/freeipa/newticket ? will do stijn rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] change min and max lifetime of random password
https://fedorahosted.org/freeipa/ticket/4272 On 03/24/2014 08:44 PM, Stijn De Weirdt wrote: hi dmitri, The whole idea of the host passwords is to be added as a part of the provisioning workflow so it should be seconds anyways. We created a smart proxy for Foreman (provisioning system) to drive host creation. It just landed upstream (first version) last week. Any chance you can use or reuse some of the code from it in your provisioning workflows? i'll have a closer looks at the code, but the goal is the same. Also can you explain why the expiration time is needed? I can understand it being needed if the password is created ahead of time and then not used for a period of time but here it is really one flow. You can't predict how much it would be 2 sec or 10 seconds but is it really important to put a cap on it? yes. we mark hosts for (re)installation and if this does not get completed within certain time, something must have gone wrong. in the meanwhile, we want this security window closed (the OTP password would be in a kickstart file, which can't be protected that easily, because it still has to work as a kickstart file). 1 day max is way too much in this context. If this is desired the right feature would be to add couple attributes to the host entry: creation time and validity interval and set them when the password is created. But it is more than a quick fix. You a welcome to file and RFE and putt all the details in the ticket. ok, will do. stijn many thanks, stijn ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] change min and max lifetime of random password
hmmm, seems like overkill to me. this should ideally be a user per host, and the user should be disabled as soon as the host is installed/has the host keytab. i can continue testing with the 1 day maximum for now. i'll track progress/discuusion via the ticket. stijn On 03/24/2014 08:53 PM, Alexander Bokovoy wrote: On Mon, 24 Mar 2014, Stijn De Weirdt wrote: hi dmitri, The whole idea of the host passwords is to be added as a part of the provisioning workflow so it should be seconds anyways. We created a smart proxy for Foreman (provisioning system) to drive host creation. It just landed upstream (first version) last week. Any chance you can use or reuse some of the code from it in your provisioning workflows? i'll have a closer looks at the code, but the goal is the same. Also can you explain why the expiration time is needed? I can understand it being needed if the password is created ahead of time and then not used for a period of time but here it is really one flow. You can't predict how much it would be 2 sec or 10 seconds but is it really important to put a cap on it? yes. we mark hosts for (re)installation and if this does not get completed within certain time, something must have gone wrong. in the meanwhile, we want this security window closed (the OTP password would be in a kickstart file, which can't be protected that easily, because it still has to work as a kickstart file). 1 day max is way too much in this context. Create user account or group of them, apply needed policy, and use these users to enroll hosts. This would work already. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] change min and max lifetime of random password
hi alexander,
No, because then you have to either ship keytabs around during
provisioning or hardcode that user's password in the kickstart and
they are already nervous about doing that for the OTP.
This topic raises regularly on IRC. My suggestion was to create these
one time passwords based on some function of time and host parameters
you can control centrally, for example, IP address.
For example, using Python expression:
from time import gmtime
addr = 192.168.0.1
time = lambda t : list(t[:4]) + [(t[4] / 15) * 15]
pw = lambda t, a: ''.join(a.split('.') + map(lambda x:
'{:02d}'.format(x), t))
pw(time(gmtime()), addr)
'19216801201403242030'
i.e. a password is an IP address octets concatenated with date and time
rounded down to 15 minutes.
Then ship the function to calculate the OTP as part of kickstart file.
Only a password generated when running install within 15 minutes window of
setting OTP on the server will work if IP address is the same as defined
on the server.
No real password is in the kickstart file, OTP will turn itself off
automatically on enrollment and time has to be within the window of
opportunity.
but the password itself is still valid if the install failed and someone
else tries to use it.
it's good that you can't guess the password that easily (it's slightly
better than a fixed string in the kickstart script), might be a good
candidate if it was coupled with a short enough lifetime. (coupled with
minimum lifetime as an offset, you might even schedule installations in
the future).
i don't understand what the ip adds to the password though. the
ipa-client-install should fail if the ip/hostname doesn't match the data
in freeipa for that host, right? (the only secret is in the timewindow
that the admin scheduled, assume that the ipa-client-install enforces
the ip/hostname)
stijn
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] CIFS and Torque/SGE
hi will, I am running FreeIPA 3.0 server on Centos 6.4. This provides authentication for Linux workstations, HPC cluster and file server. We have some Windows XP machines that need to be able to map a CIFS share, but these cannot have any clients installed due to being specialist data acquisition systems. I would like to use SSO for CIFS shares, is this possible ? And does the windows machine need to be specially configured ? As part of the HPC cluster, I need to install the queuing system and would like to use SGE or Torque. My understanding is that Torque should support krbs5, has anyone had success with Torque and FreeIPA (+NFSv4?) ? where did you get the info that torque supports krb5? (we are also running HPC and also interested in krb+nfs) stijn Any advice would be greatly received. Thanks, Will ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Announcing FreeIPA 3.2.0 Prerelease 1
hi all, what minimal OS is targeted for freeipa 3.2: FC19 or FC18? stijn On 04/02/2013 06:32 PM, Martin Kosek wrote: The FreeIPA team is proud to announce a first PRERELEASE of FreeIPA v3.2.0. We would like to welcome any early testers of this prerelase to provide us feedback and help us stabilize this feature release which we plan to release as final in the beginning of May 2013. It can be downloaded from http://www.freeipa.org/page/Downloads. The new version has also been built for Fedora 19 Alpha, if it does not appear in your Fedora 19 yet, you can download the build from koji: http://koji.fedoraproject.org/koji/buildinfo?buildID=408311 == Highlights in 3.2.0 Prerelease 1 == === New features === * Support installing FreeIPA without an embedded Certificate Authority, with user-provided SSL certificates for the HTTP and Directory servers. [1] * New cert-find command. Search certificates in the Dogtag database based on their serial number, validity or revocation details. This feature is available both as a CLI command and Web UI page. [2] * New trustconfig-show and trustconfig-mod command. Show or modify AD Trust settings generated during AD Trust installation (ipa-adtrust-install) [3] * Multiple FreeIPA servers can now be designated as Domain Controllers for trusts with Active Directory [12] * New realmdomains-show and realmdomains-mod command. Manage list of DNS domains associated with FreeIPA realm (realmdomains sommand). This list is primarily used by AD, which can pull all domains managed by FreeIPA and use that list for routing authentication requests for domains which do not match FreeIPA realm name. [4] * Support trusted domain users in HBAC test command (hbactest command). * Allow filtering incoming trusted domain SIDs per-trust (trust-mod command). [5] * Configurable PAC type for services. Service commands can now configure a set of PAC types (MS-PAC, PAD, no PAC) that are supported and handled for the service. * Faster UI loading. FreeIPA Web UI application is now packaged in minimalized format. FreeIPA web server is now also able to transmit data in compressed format. [6] [7] * UI now accepts confirmation of cancel of its dialogs via keyboard [11] * Client reenrollment. A host that has been recreated can now be reenrolled to FreeIPA server using a backed up host keytab or admin credentials [8] * Service and Host commands now provide options to add or remove selected Kerberos flags [9] === Prerelease 1 limitations === * List of DNS domains associated with FreeIPA realm currently only works with a special Samba build available for Fedora 18: http://koji.fedoraproject.org/koji/taskinfo?taskID=5184105. One needs to rebuild FreeIPA 3.2.0 prerelease 1 against this Samba version in order to get it working. * Test of trusted domain users in HBAC rules is accessible to only to members of 'Trust Admins' group due to privilege limitations * Same applies to any other trust-specific operations that require translation between user/group name and its security identifier (SID) === Bug fixes === * Fixed migration from OpenLDAP. FreeIPA is now able to migrate users and groups from OpenLDAP database instances. * Migration process is now also a lot faster and provides more debug output (to httpd error log). * SUDO rules disabled by sudorule-disable command are now removed from ou=sudoers compat tree without a need to restart 389 Directory Server instance. * Fixed LDAP schema upgrade when upgrading from a pre-2.2.0 release * Fixed server installation with external CA (--external-ca) * Consolidate on-line help system, show help without need of valid Kerberos credentials (ipa help) * New LDAP plugin (ipa_dns) has been added to add missing idnsSOASerial attribute for replicas which either do not have integrated DNS service enabled to which have disabled SOA serial autoincrement * LDAP lockout plugin has been fixed so that lockout policies are applied consistently both for LDAP binds and Kerberos authentication * ... and many others stabilization fixes, see Detailed changelog for full details == Changes in API or CLI == === Dropped --selfsign option === FreeIPA servers prior to 3.2.0 could be installed with --selfsign option. This configured the server with a NSS database based Certificate Authority with a selfsigned CA certificate and limited certificate operation support. This option was always intended for development or testing purposes only and was not intended for use in production. This release drops this option and deprecates the functionality. Current FreeIPA servers installed with --selfsigned option will still work, instructions on how to migrate to supported certificate options will be provided. FreeIPA servers version 3.2.0 and later supports the following 2 flavors of certificate management: * FreeIPA with pki-ca (dogtag) with either a self-signed certificate or with a certificate signed by external CA (--external-ca option) * FreeIPA with no pki-ca installed with certificates
Re: [Freeipa-users] mutiple domain, single realm
thanks for the info. i'll setup a test with current branch and see if that works for us. stijn On 03/26/2013 01:52 PM, Alexander Bokovoy wrote: On Tue, 26 Mar 2013, Stijn De Weirdt wrote: hi all, how can one add more domains to the same (existing) realm with ipa? we would like to bring multiple networks (some private, some public) under a single realm. as far as i understand krb5.conf, it means creating the following domain_realm section [domain_realm] .domain1 = REALM .domain2 = REALM reading the documentation, i didn't find any clues how to do this with ipa. default ipa server creation seems to assume a one-to-one mapping between domain and realm. It should be done mostly in the same way. As long as all clients and servers have these mappings configured, they should be able to work. Right now you have to maintain all these mappings manually, both at client and server sides. For 3.2 release or shortly afterwards we are trying to make it easier configurable. 3.1.3 will have 'ipa realmdomains' command to manage associated domains' list -- i.e. which DNS domains are associated with our own realm. 3.2 will have this list exposed to trusted AD domains so that they can see our topology and know where to send TGT requests (our KDCs). In addition KDC driver will be able to use the same list to augment the mapping in KDC. SSSD is also going to fetch the list like it fetches now list of trusted domains and configures them for clients. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] check host password age
i'll get back to the previous part later, wehn i can test it (thanks petr!) i guess the timestamps are somehwere in the ldap schema, i would like to know where or how i can find them. and if possible, how to do that using the ipalib python api. btw, is it correct for me to assume that when has_keytab=True that the host password is useless or even better unusable with that host? Sorry, I have to defer this question to more competent people :-) I think you could rather check that has_password=False. This effectively means that the principal has no userPassword attribute which could be used for authentication. has_keytab=True means that keys/keytab was generated, i.e. krbPrincipalKey is present. the flow as i see it is the following: a .new host, with random password : has_password=True, has_keytab=False b after succesful ipa-client-install : has_keytab=True, has_password=? c. no succesful ipa-client-install: has_password=True, has_keytab=False suppose i want to check which hosts have an old password, is should just check all nodes with has_password=True and fetch the date through ldap. but if in case b the password is still set (has_password=True), how can i disable password access? or should i not worry about passwords when has_keytab=True? stijn ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
