Re: [Freeipa-users] This again :) - ssh authentication for users in complex AD forest - where am I going wrong?

2016-11-22 Thread Simpson Lachlan
> -Original Message-
> From: Chris Dagdigian [mailto:d...@sonsorol.org]
> Sent: Wednesday, 23 November 2016 9:28 AM
> To: Simpson Lachlan
> Cc: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] This again :) - ssh authentication for users in 
> complex
> AD forest - where am I going wrong?
> 
> Simpson Lachlan wrote:
> > By no means am I an expert, but isn't there meant to be a stanza in [realm] 
> > that
> looks like this?
> >
> > auth_to_local =
> > RULE:[1:$1@$0](^.*@DOMAIN.COM$)s/@DOMAIN.COM/@domain.com/
> > auth_to_local = DEFAULT
> >
> 
> Appreciate the reply!
> 
>  From what I can tell that stanza is not needed when there is a localauth 
> provider for
> IPA (RHEL-7/Centos-7 basically) - I think the docs I read mentioned that the 
> actions
> in the stanza are automatic or implicit when localauth plugin is present.
> 
> Both my IPA box and test client are CentOS-7 at the moment so I did not do the
> extra auth_to_local rule

Oh! So do I. I don't need it either? Damn. Thanks for the tip.

Cheers
L.
This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been 
intercepted or altered and will not be liable for any delay 
in its receipt.


-- 
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] This again :) - ssh authentication for users in complex AD forest - where am I going wrong?

2016-11-22 Thread Simpson Lachlan
> -Original Message-
> From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
> boun...@redhat.com] On Behalf Of Chris Dagdigian
> Sent: Wednesday, 23 November 2016 2:37 AM
> To: freeipa-users@redhat.com
> Subject: [Freeipa-users] This again :) - ssh authentication for users in 
> complex AD
> forest - where am I going wrong?
> 
> 
> /etc/krb5.conf (IPA client)
> -
> 
> [libdefaults]
> 
>default_realm = COMPANY-IDM.ORG
>dns_lookup_realm = true
>dns_lookup_kdc = true
>rdns = false
>ticket_lifetime = 24h
>forwardable = yes
>udp_preference_limit = 0
>default_ccache_name = KEYRING:persistent:%{uid}
> 
> [realms]
> 
>COMPANY-IDM.ORG = {
>  kdc = usaeilidmp001.company-idm.org:88
>  master_kdc = usaeilidmp001.company-idm.org:88
>  admin_server = usaeilidmp001.company-idm.org:749
>  default_domain = company-idm.org
>  pkinit_anchors = FILE:/etc/ipa/ca.crt
> 
>}
> 
> [domain_realm]
> 
> ipa-client.company-aws.org = COMPANY-IDM.ORG
> 
> [capaths]
> 
> COMPANY-AWS.ORG = {
> 
>COMPANY-IDM.ORG = COMPANY-AWS.ORG
> 
> }
> 
> COMPANY-IDM.ORG = {
> 
>COMPANY-AWS.ORG = COMPANY-AWS.ORG
> 
> }

By no means am I an expert, but isn't there meant to be a stanza in [realm] 
that looks like this?

auth_to_local = RULE:[1:$1@$0](^.*@DOMAIN.COM$)s/@DOMAIN.COM/@domain.com/
auth_to_local = DEFAULT



Cheers
L.
This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been 
intercepted or altered and will not be liable for any delay 
in its receipt.


-- 
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] Password Complexity Requirements Seems Insufficient

2016-10-12 Thread Simpson Lachlan
> -Original Message-
> From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
> boun...@redhat.com] On Behalf Of Bennett, Chip
> Sent: Thursday, 13 October 2016 7:21 AM
> To: Florence Blanc-Renaud; freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] Password Complexity Requirements Seems
> Insufficient
> 
> Flo,
> 
> Thanks for getting back to me.  I had seen this in the documentation.   I was 
> just
> hoping that I was missing something.   I guess I'm just surprised that a 
> product
> designed to manage authentication wouldn't have a way to be more specific in 
> the
> complexity requirements.


I don't know. Those type of complexity requirements are multifaceted, complex 
and somewhat arbitrary. Given that each then requires regex, I'm quite happy 
that the devs focus on getting other aspects of FreeIPA to work over password 
complexity. 

As xkcd noted a couple of years ago, password length is better for security 
than anything else. 

Complex arrangements of different character classes is neither human or UX 
friendly nor where contemporary security theory is focused - try 2FA, 
public/private keys, etc. While I understand that large organisations have 
policy that often drags well behind contemporary theory, I don't think it's 
fair to expect software to also allow for that.

Cheers
L.






> 
> Thanks again!
> Chip
> 
> -Original Message-
> From: Florence Blanc-Renaud [mailto:f...@redhat.com]
> Sent: Wednesday, October 12, 2016 3:18 PM
> To: Bennett, Chip ; freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] Password Complexity Requirements Seems
> Insufficient
> 
> On 10/11/2016 07:36 PM, Bennett, Chip wrote:
> > I just joined this list, so if this question has been asked before
> > (and I'll bet it has), I apologize in advance.
> >
> >
> >
> > A google search was unrevealing, so I'm asking here: we're running
> > FreeIPA Version 3.0.0 on CentOS 6.6.   It looks like the password
> > complexity requirements are limited to setting the number of character
> > classes to require, i.e. setting it to "2" would require your new
> > password to be any two of the character classes.
> >
> >
> >
> > What if you wanted new passwords to meet specific class requirements,
> > i.e. a mix of UL, LC, and numbers.  It looks like you would use a
> > value of "3" to accomplish this, but that would also allow UC, LC, and
> > special, or LC, numbers, and special, but you don't want to allow the
> > those:  how would you specify that?
> >
> Hi,
> 
> as far as I know, it is only possible to specify the number of different 
> character
> classes. The doc chapter "Creating Password Policies in the Web UI" [1] 
> describes
> the following:
> ---
> Character classes sets the number of different categories of character that 
> must be
> used in the password. This does not set which classes must be used; it sets 
> the
> number of different (unspecified) classes which must be used in a password. 
> For
> example, a character class can be a number, special character, or capital; the
> complete list of categories is in Table 22.1, "Password Policy Settings". 
> This is part
> of setting the complexity requirements.
> ---
> 
> hope this clarifies,
> Flo
> 
> [1]
> https://access.redhat.com/documentation/en-
> US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_
> Policy_Guide/Setting_Different_Password_Policies_for_Different_User_Groups.ht
> ml#creating-group-policy-ui
> 
> 
> >
> >
> > Also, what if you had a requirement for more than one of the character
> > classes, i.e. you want to require two UC characters or two special
> > characters?
> >
> >
> >
> > Thanks in advance for the help,
> >
> > Chip Bennett
> >
> >
> >
> >
> > This message is solely for the intended recipient(s) and may contain
> > confidential and privileged information. Any unauthorized review, use,
> > disclosure or distribution is prohibited.
> >
> >
> 
> 
> This message is solely for the intended recipient(s) and may contain 
> confidential
> and privileged information.
> Any unauthorized review, use, disclosure or distribution is prohibited.
> 
> --
> 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
This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has 

Re: [Freeipa-users] In webgui, ID Views slow, to crashingly slow

2016-09-19 Thread Simpson Lachlan
> -Original Message-
> 
> On 09/19/2016 03:12 AM, Lachlan Musicman wrote:
> > Hi
> >
> > Sometimes when I visit the ID Views page in the webgui, it is
> > crushingly slow, and often it times out.
> >
> > Centos 7, ipa --version
> > VERSION: 4.2.0, API_VERSION: 2.156
> >
> > Is there a reason, can I do something to fix this?
> >
> 
> What kind of ID Views do you use? Do you use them to  override AD users?
> Is there any useful info in '/var/log/httpd/error_log'?

There is the single ID View Name, Default Trust View, and in that we have a 
number of users over riding the AD usernames and home dirs.

The httpd error log is relatively large, tbh, but there's nothing in there that 
looks like an obvious reason. In fact, for an error log, there is a hell of a 
lot of "SUCCESS" messages? The most obvious culprit in the error log is 
jsonserver_session...

Next time I see it (I only see it intermittently), I'll grab the logs and have 
a look.

Cheers
L.



This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been 
intercepted or altered and will not be liable for any delay 
in its receipt.


-- 
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] can't get sudo to work.

2016-08-23 Thread Simpson Lachlan
What version of sssd are you using?

We found that it wouldn't work w sssd<1.14

On the IPA server, it would say "yep rule applies", but then on any particular 
machine it wouldn't (well, it would - but only intermittently).

There's a COPR repo for Centos7 if you aren't on Fedora/RedHat.

Cheers
L.

-Original Message-
From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Tony Brian Albers
Sent: Tuesday, 23 August 2016 4:24 PM
To: freeipa-users@redhat.com
Subject: [Freeipa-users] can't get sudo to work.

Hi guys,

I've been trying to get sudo to work for our day-to-day admin who have their 
own usergroup in IPA called subadmin.

For some reason I can't really get sudo to work, I suspect I am missing 
something simple, but I can't really figure out what it is.

This is my config:

# ipa sudorule-find
---
1 Sudo Rule matched
---
  Rule name: All
  Enabled: TRUE
  Host category: all
  Command category: all
  User Groups: subadmin

Number of entries returned 1

#




# ipa group-find subadmin
---
1 group matched
---
  Group name: subadmin
  Description: For daily administration of users and hosts
  GID: 10003
  Member users: abr-sadm, pmd-sadm, tba-sadm, bja-sadm, alberto-ibm
  Roles: Sub-admins
  Member of Sudo rule: All

Number of entries returned 1

#





And on a client:

# cat /etc/sssd/sssd.conf
[domain/kac.lokalnet]

cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = kac.sblokalnet
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = kac-man-001.kac.lokalnet
chpass_provider = ipa
ipa_server = _srv_, kac-adm-001.kac.lokalnet ldap_tls_cacert = /etc/ipa/ca.crt 
autofs_provider = ipa ipa_automount_location = default krb5_renewable_lifetime 
= 50d krb5_renew_interval = 3600 [sssd] services = nss, sudo, pam, autofs, ssh 
config_file_version = 2

domains = kac.lokalnet
[nss]
homedir_substring = /home

[pam]

[sudo]

[autofs]

[ssh]

[pac]

[ifp]






nsswitch.conf:

passwd: files sss
shadow: files sss
group:  files sss
#initgroups: files

#hosts: db files nisplus nis dns
hosts:  files dns myhostname

# Example - obey only what nisplus tells us...
#services:   nisplus [NOTFOUND=return] files
#networks:   nisplus [NOTFOUND=return] files
#protocols:  nisplus [NOTFOUND=return] files
#rpc:nisplus [NOTFOUND=return] files
#ethers: nisplus [NOTFOUND=return] files
#netmasks:   nisplus [NOTFOUND=return] files 

bootparams: nisplus [NOTFOUND=return] files

ethers: files
netmasks:   files
networks:   files
protocols:  files
rpc:files
services:   files sss

netgroup:   files sss

publickey:  nisplus

automount:  sss files
aliases:files nisplus
sudoers:files sss




And for a subadmin account:

-sh-4.2$ sudo -l
[sudo] password for tba-sadm: 
Your password will expire in 6 day(s).
User tba-sadm is not allowed to run sudo on kac-man-001.
-sh-4.2$



Any suggestions?  Help is much appreciated.

TIA

/tony

--
Best regards,

Tony Albers
Systems administrator, IT-development
State and University Library, Victor Albecks Vej 1, 8000 Aarhus C, Denmark.
Tel: +45 8946 2316




--
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
This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been 
intercepted or altered and will not be liable for any delay 
in its receipt.


-- 
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] Unable to ssh after establishing trust

2016-07-19 Thread Simpson Lachlan
From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of pgb205
Sent: Wednesday, 20 July 2016 5:28 AM
To: Sumit Bose
Cc: Freeipa-users
Subject: Re: [Freeipa-users] Unable to ssh after establishing trust

well...I'm not sure what I changed, if anything, but I am able to login with my 
AD credentials. I have restarted ipa server and cleared sss_cache, so maybe 
that helped.

A few other things still remain though:

right now im logging in as jsmith@ADDOMAIN.LOCAL
I would want it to be either jsm...@addomain.com
or better yet
jsmith  --without specifying the domain name.

How can this be accomplished?

[Lachlan Simpson]


You are looking for the default_domain_suffix setting in the sssd stanza of 
/etc/sssd/sssd.conf

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sssd-user-ids.html

Cheers
L.



thanks


From: Sumit Bose >
To: pgb205 >
Cc: Freeipa-users >
Sent: Tuesday, July 19, 2016 3:33 AM
Subject: Re: [Freeipa-users] Unable to ssh after establishing trust

On Mon, Jul 18, 2016 at 09:21:07PM +, pgb205 wrote:
> Sumit,
>
> I have set the names of all the Domain Controllers to be resolvable to the IP
> of the one reachable Domain Controller in /etc/hosts
>
> /etc/hosts:
> Reachable_IP_BOX  172.10.10.1
> DC1172.10.10.1
> DC2172.10.10.1
> ...
> ...

The IP address should come first, please see man hosts for details.

>
> However, I still see the following
> Marking SRV lookup of service 'gc_addomain.local' as 'neutral'
> Marking server dc1.addomain.local' as 'name not resolved'

Have you tried to add the fully-qualified names (dc1.addomain.local) in
the right format (see above) to /etc/hosts?

>
>
> Additionally I have configured
> [domain/ipa.internal]
>  with
> subdomain_inherit = ldap_user_principal
> ldap_user_principal = nosuchattr
>
>
> As far as your earlier note about seeing ewr-fipa-x1 in logs. That used to be
> the old hostname of the IPA KDC.
> After much troubleshooting I believe I got this fixed by deleting  extra
> folders in
> /var/named/dyndb-ldap/ipa/master
> Right now the only two folders are ipa.internal and .in-addr.arpa.
> I think this is what helped with this issue. but can you please confirm if it
> sounds reasonable.

Not sure how you got the additional directories but if on only have a
single IPA DNS domain the two directories are sufficient.

bye,

Sumit

>
>
> Ssh is still failing, possibly due to the problem 1 above. Is there anything
> else I can do to force ipa to pay attention to the /etc/hosts ?
> Or is this some other issue?
>
> thanks
> ━━━
> From: Sumit Bose >
> To: pgb205 >
> Cc: Sumit Bose >; Freeipa-users 
> >
> Sent: Wednesday, July 13, 2016 5:43 AM
> Subject: Re: [Freeipa-users] Unable to ssh after establishing trust
>
> On Tue, Jul 12, 2016 at 06:40:22PM +, pgb205 wrote:
> > +freeipa-users list
> >
> >  From: pgb205 >
> >  To: Sumit Bose >
> >  Sent: Tuesday, July 12, 2016 2:12 PM
> >  Subject: Re: [Freeipa-users] Unable to ssh after establishing trust
> >
> > Sumit, thanks for replying
> > So the first issue is my fault, probably from when I was sanitizing logs.
> > our active directory domain is ad_domain.local, but users would expect to
> login as userid@ad_domain.com or just userid.for 
> ipa the kerberos realm is
> IPA_DOMAIN.INTERNAL and domain is ipa_domain.internal.
> > ewr-fipa_server used to be old trial server so I am not sure why it's still
> in the dns lookup results. I'll check this part further.
> > Lastly. only the connection to one of the domain controllers on AD side is
> open. As discussed previously with Alexandr BokovoyI forced, in 
> /etc/krb5.conf,
> a connection to this single, accessible domain controller. Are there any other
> files where I would needto lock down the connections between ipa->ad so that
> all traffic goes to specific active directory domain controller?
> > thanks again for replying so quickly.
>
> Currently it is not possible to specify individual AD DC SSSD on the IPA
> server should talk to. We have ticket
> https://fedorahosted.org/sssd/ticket/2599 to make this possible in some
> later versions of SSSD.
>
> Currently SSSD uses a DNS SRV lookup like _ldap._tcp.ad_domain.local to
> get a list of AD DC, then picks one to get the next nearest site for the
> IPA domain and finally 

Re: [Freeipa-users] Inconsistant results with HBAC and SSH?

2016-05-26 Thread Simpson Lachlan
> With the “allow all” HBAC rule enabled, we have no trouble logging in to any
> machine via ssh. When we disable the “allow all” rule and make specific per-
> machine rules (as per the idea of ‘host based’ in HBAC), we get unpredictable
> results, primarily resulting in an inability to login via ssh. This result is 
> intermittent
> – sometimes we can login, but sometimes we can’t.

One noted way to "break" the HBAC is a long period of inactivity in that shell.

Cheers
L.
This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been 
intercepted or altered and will not be liable for any delay 
in its receipt.


-- 
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] Inconsistant results with HBAC and SSH?

2016-05-26 Thread Simpson Lachlan
With the “allow all” HBAC rule enabled, we have no trouble logging in to any 
machine via ssh. When we disable the “allow all” rule and make specific 
per-machine rules (as per the idea of ‘host based’ in HBAC), we get 
unpredictable results, primarily resulting in an inability to login via ssh. 
This result is intermittent – sometimes we can login, but sometimes we can’t.



HBAC has been created and appears fine on server
[root@vmpr-linuxidm ~]# ipa hbactest --user="pmci\ellul jason" 
--host=emts-facs.unix.petermac.org.au --service=ssh

Access granted: True

  Matched rules: ad_users
  Matched rules: allow_all
  Matched rules: FACS Computing
  Not matched rules: Computing Cluster


Using the allow_all HBAC all users can log in fine but if we disable it users 
can no longer always login. When the user tries to log in we see the following 
on the host sssd logs:

[sssd[be[unix.petermac.org.au]]] [sdap_parse_entry] (0x1000): OriginalDN: 
[ipaUniqueID=34fb2be6-2137-11e6-9853-005056b00bfd,cn=hbac,dc=unix,dc=petermac,dc=org,dc=au].
[sssd[be[unix.petermac.org.au]]] [sdap_get_generic_op_finished] (0x0400): 
Search result: Success(0), no errmsg set
[sssd[be[unix.petermac.org.au]]] [hbac_attrs_to_rule] (0x1000): Processing rule 
[ad_users]
[sssd[be[unix.petermac.org.au]]] [hbac_user_attrs_to_rule] (0x1000): Processing 
users for rule [ad_users]
[sssd[be[unix.petermac.org.au]]] [hbac_service_attrs_to_rule] (0x1000): 
Processing PAM services for rule [ad_users]
[sssd[be[unix.petermac.org.au]]] [hbac_get_category] (0x0200): Category is set 
to 'all'.
[sssd[be[unix.petermac.org.au]]] [hbac_thost_attrs_to_rule] (0x1000): 
Processing target hosts for rule [ad_users]
[sssd[be[unix.petermac.org.au]]] [hbac_get_category] (0x0200): Category is set 
to 'all'.
[sssd[be[unix.petermac.org.au]]] [hbac_shost_attrs_to_rule] (0x0400): 
Processing source hosts for rule [ad_users]
[sssd[be[unix.petermac.org.au]]] [hbac_attrs_to_rule] (0x1000): Processing rule 
[FACS Computing]
[sssd[be[unix.petermac.org.au]]] [hbac_user_attrs_to_rule] (0x1000): Processing 
users for rule [FACS Computing]
[sssd[be[unix.petermac.org.au]]] [hbac_service_attrs_to_rule] (0x1000): 
Processing PAM services for rule [FACS Computing]
[sssd[be[unix.petermac.org.au]]] [hbac_get_category] (0x0200): Category is set 
to 'all'.
[sssd[be[unix.petermac.org.au]]] [hbac_thost_attrs_to_rule] (0x1000): 
Processing target hosts for rule [FACS Computing]
[sssd[be[unix.petermac.org.au]]] [hbac_shost_attrs_to_rule] (0x0400): 
Processing source hosts for rule [FACS Computing]
[sssd[be[unix.petermac.org.au]]] [hbac_eval_user_element] (0x1000): [41] groups 
for [Ellul ja...@petermac.org.au]
[sssd[be[unix.petermac.org.au]]] [ipa_hbac_evaluate_rules] (0x0080): Access 
denied by HBAC rules
[sssd[be[unix.petermac.org.au]]] [be_pam_handler_callback] (0x0100): Backend 
returned: (0, 6, ) [Success (Permission denied)]
[sssd[be[unix.petermac.org.au]]] [be_pam_handler_callback] (0x0100): Sending 
result [6][petermac.org.au]
[sssd[be[unix.petermac.org.au]]] [be_pam_handler_callback] (0x0100): Sent 
result [6][petermac.org.au]
[sssd[pam]] [pam_dp_process_reply] (0x0200): received: [6 (Permission 
denied)][petermac.org.au]
[sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [6]: Permission 
denied.
[sssd[pam]] [pam_reply] (0x0200): blen: 32
[sssd[pam]] [client_recv] (0x0200): Client disconnected!
[sssd[nss]] [client_recv] (0x0200): Client disconnected!


Which states Access denied by HBAC rules.

On server we still see
[root@vmpr-linuxidm ~]# ipa hbactest --user="pmci\ellul jason" 
--host=emts-facs.unix.petermac.org.au --service=ssh

Access granted: True

  Matched rules: ad_users
  Matched rules: FACS Computing
  Not matched rules: Computing Cluster

[root@vmpr-linuxidm ~]# ipa hbacrule-show
Rule name: ad_users   
  Rule name: ad_users
  Host category: all
  Service category: all
  Enabled: TRUE
  User Groups: ad_users

[root@vmpr-linuxidm ~]# ipa hbacrule-show
Rule name: FACS Computing
  Rule name: FACS Computing
  Service category: all
  Description: This server is running Flow Logic. Current server name is 
emts-facs.unix.petermac.org.au
  Enabled: TRUE
  User Groups: facs-compute
  Hosts: emts-facs.unix.petermac.org.au


On the host (emts-facs.unix.petermac.org.au) it shows the user is in the 
correct groups: 10011(facs-compute) and 171884(ad_users) which are both 
posix groups local to freeIPA

[root@emts-facs ~]# id "pmci\ellul jason"
uid=1501(jel...@petermac.org.au) gid=1501(jellul) 
groups=1501(jellul),1750642900(secure file transfer 
us...@petermac.org.au),10011(facs-compute),10004(bioinf-core),10005(rcf-staff),171884(ad_users)
 (NB: group list truncated for brevity)

Cheers
L.
This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the 

Re: [Freeipa-users] AD replication and password passthrough

2016-05-24 Thread Simpson Lachlan
We were doing this by utilising overrides (changing user names, /home/ s, etc), 
but I think we had to back out of that plan because we encountered issues. We 
may go back.

Using Host Based Access Control (HBAC) and sudo is a powerful set of tools. 
What did you want to do that wasn’t covered by those three?


L.


From: Redmond, Stacy [mailto:stacy.redm...@blueshieldca.com]
Sent: Wednesday, 25 May 2016 9:15 AM
To: Simpson Lachlan
Subject: RE: AD replication and password passthrough

I am replacing ODS, and would like to replicate AD (ad.foo.com) to my new IPA 
installation (ipa.foo.com) but in all the documentation it says I have to 
install passsync on AD to synchronize passwords, I would rather just tell ipa 
to authorize the user via password from AD.

I have a one way trust setup now, just would rather have everything in IPA, but 
use AD passwords due to new requirements.

From: Simpson Lachlan [mailto:lachlan.simp...@petermac.org]
Sent: Tuesday, May 24, 2016 4:09 PM
To: Redmond, Stacy 
<stacy.redm...@blueshieldca.com<mailto:stacy.redm...@blueshieldca.com>>
Subject: RE: AD replication and password passthrough

** BSCA security warning: Do not click links or trust the content unless you 
expected this email and trust the sender – This email originated outside of 
Blue Shield. **
It depends on what you mean.

If, by replication, you mean using FreeIPA as a backup AD server, it would need 
to be a two way trust.

If you have a separate subdomain, it’s definitely possible with a one way trust.

Cheers
L.

From: freeipa-users-boun...@redhat.com<mailto:freeipa-users-boun...@redhat.com> 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Redmond, Stacy
Sent: Tuesday, 24 May 2016 3:15 AM
To: freeipa-users@redhat.com<mailto:freeipa-users@redhat.com>
Subject: [Freeipa-users] AD replication and password passthrough

Is there a way to setup replication from AD, and just use passthrough to AD for 
passwords, vs having to synchronize passwords.  I am getting a lot of pushback 
from the AD team on installing the password sync software due to issues in the 
past.  I would like to setup replication, but still use AD to authenticate 
passwords.
This email (including any attachments or links) may contain confidential and/or 
legally privileged information and is intended only to be read or used by the 
addressee. If you are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly prohibited. Confidentiality and 
legal privilege attached to this email (including any attachments) are not 
waived or lost by reason of its mistaken delivery to you. If you have received 
this email in error, please delete it and notify us immediately by telephone or 
email. Peter MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been intercepted or altered 
and will not be liable for any delay in its receipt.
This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been 
intercepted or altered and will not be liable for any delay 
in its receipt.

-- 
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] File user and group ownership listings...

2016-05-19 Thread Simpson Lachlan
> -Original Message-
> From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
> boun...@redhat.com] On Behalf Of Alexander Bokovoy
> Sent: Thursday, 19 May 2016 5:12 PM
> To: Lachlan Musicman
> Cc: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] File user and group ownership listings...
> 
> On Thu, 19 May 2016, Lachlan Musicman wrote:
> >Now that groups are working as expected, we have noticed that when
> >listing a directory the user and group now have full domain qualifiers.
> >
> >This doesn't look great. We've also noticed that we now need to
> >
> >chown :group@subdomain filename
> >
> >(with default_domain_suffix set).
> >
> >
> >Is there a reason why when the group's name and ID is the same across
> >both domains, it can't be considered the same group for file ownership 
> >reasons?
> In POSIX systems user and group IDs are two different namespaces. We force
> so-called private groups to have the same ID as the user to simplify some of 
> hard
> identity mapping problems between POSIX and Windows environments. In
> Windows world security identifier (SID) namespace is the same for all objects.

Ah, ok then. Thanks!

Cheers
L.
This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been 
intercepted or altered and will not be liable for any delay 
in its receipt.


-- 
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] File user and group ownership listings...

2016-05-19 Thread Simpson Lachlan
> -Original Message-
> From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
> boun...@redhat.com] On Behalf Of Jakub Hrozek
> Sent: Thursday, 19 May 2016 5:22 PM
> To: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] File user and group ownership listings...
> 
> On Thu, May 19, 2016 at 04:33:45PM +1000, Lachlan Musicman wrote:
> > Now that groups are working as expected, we have noticed that when
> > listing a directory the user and group now have full domain qualifiers.
> >
> > This doesn't look great. We've also noticed that we now need to
> >
> > chown :group@subdomain filename
> 
> This is something that will work in 7.3. There is currently a limitation in 
> our cache
> that forces us to use fully-qualified names for users from trusted domains.

Fantastic. Thanks for all the hard work!


Cheers
L.  

This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been 
intercepted or altered and will not be liable for any delay 
in its receipt.


-- 
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 group membership

2016-05-19 Thread Simpson Lachlan
> -Original Message-
> From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
> boun...@redhat.com] On Behalf Of Alexander Bokovoy
> Sent: Thursday, 19 May 2016 4:07 PM
> To: Lachlan Musicman
> Cc: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] AD group membership
> 
> On Thu, 19 May 2016, Lachlan Musicman wrote:
> >Hi,
> >
> >We seem to have some progress, after reading this blog post about sssd
> >performance tuning.
> >
> >https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-la
> >rge-ipa-ad-trust-deployments/
> >
> >So now we see that on the FreeIPA server, everything is stable and
> >always produces the results we expect with regard to users and group
> membership.
> >It's also a bit speedier, which is nice.
> >
> >Unfortunately, on the clients, we are still seeing groups "disappearing"
> >occasionally,
> You've been told in another thread to upgrade IPA and SSSD packages to what is
> in CentOS 7 updates. There was recently (May 12th) a release of RHEL 7.2.4
> updates which CentOS already picked up. This release included fixes to
> incomplete group membership you mention.


Yes - it seems to be working and stable, even post reboot. Thanks for your help.

Cheers
L.
This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been 
intercepted or altered and will not be liable for any delay 
in its receipt.


-- 
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] HBAC access denied, all AD groups not detected

2016-05-18 Thread Simpson Lachlan
> -Original Message-
> From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
> boun...@redhat.com] On Behalf Of Jakub Hrozek
> Sent: Wednesday, 18 May 2016 5:40 PM
> To: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] HBAC access denied, all AD groups not detected
> 
> On Wed, May 18, 2016 at 08:35:14AM +1000, Lachlan Musicman wrote:
> > Hmmm, I also now see
> >
> > https://fedorahosted.org/sssd/ticket/2642
> > and
> > https://bugzilla.redhat.com/show_bug.cgi?id=1217127
> >
> > Versions being run:
> >
> > sssd-client-1.13.0-40.el7_2.4.x86_64
> > sssd-ad-1.13.0-40.el7_2.4.x86_64
> > sssd-proxy-1.13.0-40.el7_2.4.x86_64
> > sssd-1.13.0-40.el7_2.4.x86_64
> > sssd-common-1.13.0-40.el7_2.4.x86_64
> > sssd-common-pac-1.13.0-40.el7_2.4.x86_64
> > sssd-ipa-1.13.0-40.el7_2.4.x86_64
> > sssd-ldap-1.13.0-40.el7_2.4.x86_64
> > python-sssdconfig-1.13.0-40.el7_2.4.noarch
> > sssd-krb5-common-1.13.0-40.el7_2.4.x86_64
> > sssd-krb5-1.13.0-40.el7_2.4.x86_64
> >
> > ipa-server-trust-ad-4.2.0-15.0.1.el7.centos.6.1.x86_64
> 
> The reason I asked about the server versions is
> https://bugzilla.redhat.com/show_bug.cgi?id=1304333
> 
> I'm not too familiar with how the centos versioning works, can you check if 
> that
> bug is mentioned in the rpm changelog?


"You are not authorized to access bug #1304333." :(
This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been 
intercepted or altered and will not be liable for any delay 
in its receipt.


-- 
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 Primary Groups are ignored in FreeIPA?

2016-05-17 Thread Simpson Lachlan
> -Original Message-
> From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
> boun...@redhat.com] On Behalf Of Alexander Bokovoy
> Sent: Monday, 16 May 2016 11:46 PM
> To: Lachlan Musicman
> Cc: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] AD Primary Groups are ignored in FreeIPA?
> 
> On Mon, 16 May 2016, Lachlan Musicman wrote:
> >Hola,
> >
> >We have an interesting scenario that is hard to find any information on.
> >
> >Due to permission restrictions, a NAS that is mounted and visible by
> >both AD and 'nix clients, every user belongs to a particular primary group.
> What scope these primary groups have in AD?

They are a mix of Global and Universal.

> >When we try doing idoverride's on the groups, it fails with the Primary
> >Group. In some cases, the primary group doesn't even appear in a getent
> >or id request. Sometimes it appears with incorrect name or GID.
> >
> >We have found it hard to get repeatable "failures", but here are two:
> >
> >1. getent group  (where groupname is any group, but is a
> >primary group for a subset of members)
> >
> > - does not return any member that has groupname as a primary group in AD.
> >
> >2. Overriding a group
> >
> >if the user has that group as a primary group (in AD), it will override
> >the name, but not the GID.
> >else, the override works.
> >
> >There were a number of other unusual results that are hard to explain
> >how to reproduce because it was all so seemingly random.
> Primary groups in AD are a bit complex. SSSD needs to improve on their 
> handling
> as, for example, Samba only recognizes primary groups from AD, not any others,
> and there should be some coherence to make things actually work correctly.

Yep - for us it's a samba issue at the bottom (the last yak to shave is the 
samba straddling both windows and linux domains, which is a solved 
problem/fixed constraint).

>
> >I feel like it would be an obvious need - to translate or override AD
> >primary groups to FreeIPA groups, but this doesn't seem possible.
> There is only one primary group for a user. For Kerberos operations we 
> currently
> don't take ID overrides into account when constructing MS-PAC, so if AD users
> comes with GSSAPI to a FreeIPA client, its primary group SID will stay pinned 
> to
> AD's group, ignoring ID overrides.

What is MS-PAC?

> I'm not sure it would be possible to amend primary group SIDs with ID 
> overrides in
> general because a numeric value in the override for a gid does not mean there 
> is
> an actual group with a proper SID and name in FreeIPA for that gid.


Not interested in changing the SID. I want to change the GID. When the AD 
groups are read in FreeIPA they are given a GID like 171880.

I want that GID to be the same as it is in AD - eg 10004. That way, when a user 
rights to the shared drive on the linux side, the file is given the group 
ownership 10004. Which, when read on the Windows side, correctly maps to a 
group of users (instead of an individual). This is working in the current 
non-IPA system, but that system is not integrated. We want to integrate, hence 
FreeIPA.

> There is another issue, though. If a users' primary group has a domain local
> scope, FreeIPA will not be able to use that group through the forest 
> boundary, at
> least, it should be ignored according to the AD specs.

Ah, hence the scope question. 

No, none are Domain Local to my knowledge. 

Cheers
L.
This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been 
intercepted or altered and will not be liable for any delay 
in its receipt.


-- 
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 Primary Groups are ignored in FreeIPA?

2016-05-17 Thread Simpson Lachlan
> -Original Message-
> From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
> boun...@redhat.com] On Behalf Of Martin Kosek
> Sent: Monday, 16 May 2016 11:28 PM
> To: Lachlan Musicman; freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] AD Primary Groups are ignored in FreeIPA?
> 
> On 05/16/2016 05:28 AM, Lachlan Musicman wrote:
> > Hola,
> >
> > We have an interesting scenario that is hard to find any information on.
> >
> > Due to permission restrictions, a NAS that is mounted and visible by
> > both AD and 'nix clients, every user belongs to a particular primary group.
> >
> > When we try doing idoverride's on the groups, it fails with the Primary 
> > Group.
> > In some cases, the primary group doesn't even appear in a getent or id 
> > request.
> > Sometimes it appears with incorrect name or GID.
> >
> > We have found it hard to get repeatable "failures", but here are two:
> >
> > 1. getent group  (where groupname is any group, but is a
> > primary group for a subset of members)
> >
> >   - does not return any member that has groupname as a primary group in AD.
> >
> > 2. Overriding a group
> >
> > if the user has that group as a primary group (in AD), it will
> > override the name, but not the GID.
> > else, the override works.
> >
> > There were a number of other unusual results that are hard to explain
> > how to reproduce because it was all so seemingly random.
> >
> >
> > I feel like it would be an obvious need - to translate or override AD
> > primary groups to FreeIPA groups, but this doesn't seem possible.
> >
> > Have we set IPA  up incorrectly, or are we hitting on something else?
> >
> > I found this AD support problem for Win2003, but I feel like it's old
> > and would surely have been solved?
> > https://support.microsoft.com/en-us/kb/275523
> >
> > Also, their solution ("hack AD, then hack your other LDAP software")
> > is, for some reason, funny to me.
> 
> It seems you are looking for this extension:
> https://fedorahosted.org/sssd/ticket/1872
> 
> It is not done yet, there is a plenty of information in the ticket comments.
> Please let us know if this does not help.

Martin,

Thanks for your response. This doesn't quite fit our issues. This is explicitly 
about *private* groups in NIX (where adding new user creates GID==UID and 
enrols that user).

Our problem is explicitly a *Primary Groups in AD* problem. Users that exist in 
AD have a primary group (traditionally "Domain Users") which we are using for 
other reasons (access control based on groups to files that are mounted on both 
AD and NIX servers).

In FreeIPA ( ipa-server-4.2.0-15.0.1.el7.centos.6.1.x86_64 on fully up to date 
Centos 7.2), after joining the AD (domain.org) in a one way trust as a 
subdomain (unix.domain.org), when we query AD, it explicitly ignores AD based 
Primary Groups - membership and overrides seem to fail.

Does that make sense?

I can see that it's vaguely related to the private group, but only in so much 
as it's the group that is assigned to the user (if you look in /etc/passwd on 
our pre-IPA system, our user data look like: 
lsimpson:x:1542:10007::/home/lsimpson:/bin/bash where 10007 is the id of the 
primary group in AD).

Obviously this data is no longer in /etc/passwd, but it doesn't seem to be able 
to be affected (via idoverrides).

Cheers
L.
This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been 
intercepted or altered and will not be liable for any delay 
in its receipt.


-- 
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] After successful ipa-client-install, sssd not used?

2016-05-15 Thread Simpson Lachlan
> -Original Message-
> From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
> boun...@redhat.com] On Behalf Of Jakub Hrozek
> Sent: Monday, 16 May 2016 1:32 AM
> To: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] After successful ipa-client-install, sssd not 
> used?
> 
> SSSD doesn't log anything except critical failures by default. Please follow
> https://fedorahosted.org/sssd/wiki/Troubleshooting to see what's going on on 
> the
> client.


Thanks. Turns out the AD DNS had some bad entries that were poisoning our 
results. They have been solved now.

Cheers
L.
This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been 
intercepted or altered and will not be liable for any delay 
in its receipt.


-- 
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] Removing the requirement to add domain to users login

2016-03-22 Thread Simpson Lachlan
Stacy

With regard to you first problem, IIRC you can have it default to a single 
domain – it doesn’t matter which. Users from the other domain, will need to 
login via the

u...@my.other.domain.com

I had exactly this problem. If you want to change it, it’s the 
default_domain_suffix option.

Cheers
L.


From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Redmond, Stacy
Sent: Wednesday, 23 March 2016 12:44 PM
To: freeipa-users@redhat.com
Subject: [Freeipa-users] Removing the requirement to add domain to users login

I have been tasked with setting up an IPA AD trust.  I have my ipa server 
setup, the trust is setup, and appears to be working for the most part.  I have 
two problems.  I would like for users to login with userid only.  Right now I 
can only login using userid@ad_domain   I am hoping there is some way to just 
have it search that domain as well as the default ipa domain

I will add my other problem, but am willing to send a second email to the group 
if needed.  When I login to my linux client and type id, I see lots of groups 
but they don’t all match the member of list I pull using an ldap search of AD.

IPA Server:  RHEL 7.2  ipa 4.2
Client:  RHEL 7.2
This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been 
intercepted or altered and will not be liable for any delay 
in its receipt.

-- 
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] Version name changed?

2016-03-03 Thread Simpson Lachlan
Hi,

I have just installed Spacewalk to manage my servers and I noticed that the 
FreeIPA wanted to update some packages.

My FreeIPA server is Centos 7.

I notices in Spacewalk that the ipa-server package (and various bits) wanted to 
update, and the relevant versions were:

Installed packages:  

ipa-server-4.2.0-15.el7.centos.3.x86_64

Update candidates: 

ipa-server-4.2.0-15.el7_2.6.x86_64


Why has the naming structure changed from 

*el7.centos.3.*

to

*el7_2.6*

?

Cheers
L.  
This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been 
intercepted or altered and will not be liable for any delay 
in its receipt.


-- 
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] Client Host isn't picking up the idduseroverrides

2016-02-03 Thread Simpson Lachlan
When my users log into the IPA server, the id user over rides work.

But they don't when we log into a client host?

What are we doing wrong?

The overrides are in the "Default Trust View" so should be applied to all hosts.

We are trying to find *why* and *where* this is failing, but without much 
success.

>From what I've read, this should be controlled by the sssd service on the 
>host, but if we run sssd -I to watch what happens during a failed login or a 
>login that doesn't successfully get the id user over ride applied, we don't 
>see any errors or log entries that would indicate why.

We see this:

[root@vmts-linux1 ~]# /usr/sbin/sssd -i
[sssd[be[unix.example.org]]] [krb5_auth_store_creds] (0x0010): unsupported PAM 
command [249].
[sssd[be[unix.example.org]]] [krb5_auth_store_creds] (0x0010): password not 
available, offline auth may not work.

But there isn't anything in any logs that would indicate there's a 
communication happening between the host and the server that we can see.

We have tried sss_cache -E on the host to clear cache, but we still aren't 
getting the over rides.

Cheers
L.
This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been 
intercepted or altered and will not be liable for any delay 
in its receipt.


-- 
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] "Installing the client"

2016-02-02 Thread Simpson Lachlan
In the docs, there is a section called "Installing the client".

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#setting-up-clients

The very first step contains language that is not explained.

"For a regular user system" has one install method, and "An administrator 
machine" has another.

There is no indication what an administrator machine might be used for - is 
this a replica? Is it a system that can run ipa commands on behalf of the 
ipa-server? 

What is the difference between a regular user system and an administrator 
machine?

Cheers
L.  
This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been 
intercepted or altered and will not be liable for any delay 
in its receipt.


-- 
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] Joining a host

2016-02-02 Thread Simpson Lachlan
Hola,

Presuming a regular machine, I've started the join as per instructions:

yum install ipa-client

[root@vmts-linux1 ~]# ipa-client-install
Error checking LDAP: Operations error: 04DC: LdapErr: DSID-0C0906E8, 
comment: In order to perform this operation a successful bind must be completed 
on the connection., data 0, v1db1
Discovery was successful!
Client hostname: vmts-linux1.unix.example.org
Realm: UNIX.EXAMPLE.ORG
DNS Domain: unix.example.org
IPA Server: dc1.example.org
BaseDN: dc=unix,dc=example,dc=org


There are two things here that I'd like to understand.

1. There was an error, but the process seems to have been successful? Should I 
be investigating that error or is it to be expected?
2. The IPA server is wrong - the machine it has found the PDC  server (with a 
one way trust IPA->AD), but not the IPA server. I can only presume this is in 
error and that I should run the command again explicitly stating the IPA server?

Cheers
L.
This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been 
intercepted or altered and will not be liable for any delay 
in its receipt.


-- 
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] User mapping between domains

2016-02-02 Thread Simpson Lachlan
> -Original Message-
> From: Simpson Lachlan
> 
> and that via the ID Views Default Trust View the IPA server would:
>  - see that jsmith is "Smith Jane" in AD
>  - authenticate against "Smith Jane"'s AD password
>  - see that jsmith's uid now needs to be 1500 instead of 17890983
>  - see that jsmith's home should be /home/jsmith, creating this dir if it
> doesn't exist
>  - see that jsmith's shell is /bin/bash

I should add:

 - how do I clear the SSSD cache on client hosts when details change upstream?
 - the documentation mentioned - 
http://www.freeipa.org/page/V4/Migrating_existing_environments_to_Trust#How_to_Test
 - indicates that after applying an override via command line like:

ipa idoverrideuser-add 'Default Trust View' 
testu...@tbad.idm.lab.eng.brq.redhat.com  --uid 

we need to follow this up with a restart of SSSD.

I've not known this to be sufficient. I cannot give a "sufficient" way to make 
this override stick - "magic hand waving" that has worked for me includes: 
restarting SSSD twice, rebooting the IPA server, and sometimes it seems that 
after a .

Am I missing something?

Cheers
L.

Details:

Centos 7.2
 
sssd-common-1.13.0-40.el7_2.1.x86_64
sssd-ad-1.13.0-40.el7_2.1.x86_64
sssd-1.13.0-40.el7_2.1.x86_64
python-sssdconfig-1.13.0-40.el7_2.1.noarch
sssd-krb5-common-1.13.0-40.el7_2.1.x86_64
sssd-ipa-1.13.0-40.el7_2.1.x86_64
sssd-ldap-1.13.0-40.el7_2.1.x86_64
sssd-proxy-1.13.0-40.el7_2.1.x86_64
sssd-client-1.13.0-40.el7_2.1.x86_64
sssd-common-pac-1.13.0-40.el7_2.1.x86_64
sssd-krb5-1.13.0-40.el7_2.1.x86_64


cheers
L.
This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been 
intercepted or altered and will not be liable for any delay 
in its receipt.


-- 
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 mapping between domains

2016-02-02 Thread Simpson Lachlan
IPA is successfully installed, a one way trust created, and we have been able to
login using AD credentials.

For future googler's, there is some bare bones documentation on how to allow AD 
users to login to your system, under the heading "Allow access for users from AD
domain to protected resources"

http://www.freeipa.org/page/Active_Directory_trust_setup#Configure_IPA_server_for_cross-realm_trusts

I can confirm this works for a one directional trust (IPA trusts AD), since that
is what we have.

Question/Issue:

Currently I have two logins, one in the AD domain and one on each server in 
the IPA domain. The desire is to close that gap. 

We were under the impression that, utilising idoverrideuser, that we could map 
AD's 

"Smith Jane"@example.org (or EXAMPLE\Jane Smith; yes I know our AD logins 
have spaces in them, it's a technical debt that has no solution roadmap within 
the org) to

jsm...@unix.example.org (which we would set up in IPA), 

and be able to override certain aspects, like:

 - instead of using the clumsy 

ssh "Smith Jane"@example@host1.unix.example.org 

to login to a system, we could use:

ssh jsm...@host1.unix.example.org

and that via the ID Views Default Trust View the IPA server would:
 - see that jsmith is "Smith Jane" in AD
 - authenticate against "Smith Jane"'s AD password
 - see that jsmith's uid now needs to be 1500 instead of 17890983
 - see that jsmith's home should be /home/jsmith, creating this dir if it 
doesn't exist
 - see that jsmith's shell is /bin/bash

Am I merely imagining that this is possible?

My information came from various blog posts on the RH blog that suggested such a
thing was possible, and this post on the FreeIPA site:

http://www.freeipa.org/page/V4/Migrating_existing_environments_to_Trust#ID_Views

Given the above use case, can I please get advice on:

 - is there a preferred order in which IPA user (jsm...@unix.example.org) is 
created and AD user (EXAMPLE\Smith Jane) has their ID Views Default Trust 
View entry created? 
 - for the creation of homedir on login, does this need to be done per host, via
ipa-client-install's --mkhomedir option rather than per user?


Have I missed something?

Cheers
L.


This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been 
intercepted or altered and will not be liable for any delay 
in its receipt.


-- 
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] FW: Joining a host

2016-02-02 Thread Simpson Lachlan


> -Original Message-
> From: Simpson Lachlan
> Sent: Wednesday, 3 February 2016 9:50 AM
> To: Simpson Lachlan
> Subject: RE: Joining a host
> 
> > -Original Message-
> > From: Simpson Lachlan
> >
> > [root@vmts-linux1 ~]# ipa-client-install Error checking LDAP: Operations 
> > error:
> > 04DC: LdapErr: DSID-0C0906E8, comment: In order to perform this
> > operation a successful bind must be completed on the connection., data
> > 0, v1db1 Discovery was successful!
> > Client hostname: vmts-linux1.unix.example.org
> > Realm: UNIX.EXAMPLE.ORG
> > DNS Domain: unix.example.org
> > IPA Server: dc1.example.org
> > BaseDN: dc=unix,dc=example,dc=org
> >
> 
> Interestingly, if I choose to explicitly put the IPA server name, I get dire 
> warnings
> of no DNS autodiscover.
> 
> The man page states:
> 
> "Client machine can also be configured without a DNS autodiscovery at all. 
> When
> both --server and --domain options are used, client installer will use the 
> specified
> server and domain directly."
> 
> 
> [root@vmts-linux1 ~]# ipa-client-install 
> --server=vmts-linuxidm.unix.example.org
> Usage: ipa-client-install [options]
> 
> ipa-client-install: error: --server cannot be used without providing --domain
> 
> [root@vmts-linux1 ~]# ipa-client-install 
> --server=vmts-linuxidm.unix.example.org -
> -domain=unix.example.org Autodiscovery of servers for failover cannot work 
> with
> this configuration.
> If you proceed with the installation, services will be configured to always 
> access
> the discovered server for all operations and will not fail over to other 
> servers in
> case of failure.
> Proceed with fixed values and no DNS discovery? [no]:
> 
> 
> I think we now have two solid conclusions:
> 
>  - there are DNS issues in my domain that I need to fix up (why isn't
> _ldap._tcp.unix.example.org resolving to the IPA server?)
>  - the man page should clearly state that --server can't be run without the 
> --domain
> option, unless it can, and the error message is wrong.
> 
> Cheers
> L.

This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been 
intercepted or altered and will not be liable for any delay 
in its receipt.


-- 
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] Joining a host

2016-02-02 Thread Simpson Lachlan
> > -Original Message-
> > From: Simpson Lachlan
> > Sent: Wednesday, 3 February 2016 9:50 AM

> >
> > [root@vmts-linux1 ~]# ipa-client-install
> > --server=vmts-linuxidm.unix.example.org - -domain=unix.example.org
> > Autodiscovery of servers for failover cannot work with this configuration.
> > If you proceed with the installation, services will be configured to
> > always access the discovered server for all operations and will not
> > fail over to other servers in case of failure.
> > Proceed with fixed values and no DNS discovery? [no]:
> >
> >
> > I think we now have two solid conclusions:
> >
> >  - there are DNS issues in my domain that I need to fix up (why isn't
> > _ldap._tcp.unix.example.org resolving to the IPA server?)
> >  - the man page should clearly state that --server can't be run
> > without the --domain option, unless it can, and the error message is wrong.


Sure enough, #1 was true, and when the DNS entries for _ldap._tcp and 
_kerberos._tcp within that domain were fixed, running ipa-client-install worked 
exactly as expected.

Cheers
L.
This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been 
intercepted or altered and will not be liable for any delay 
in its receipt.


-- 
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] ipa-trust and SRV records

2016-01-26 Thread Simpson Lachlan
At the end of the installation of the ipa-adtrust-install, there is a message 
along the lines of:



Add the following service records to your DNS server for DNS zone 
unix.co.org.au:

 _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs
 _ldap._tcp.dc._msdcs
 _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs
 _kerberos._tcp.dc._msdcs
 _kerberos._udp.Default-First-Site-Name._sites.dc._msdcs
 _kerberos._udp.dc._msdcs


Which has, I think, been the cause of all of my grief.

Do these SRV records in AD represent the minimum DNS set up required in Active 
Directory (my setup is a one way trust from FreeIPA to an AD over which I have 
no control, and all DNS is passed up to AD)?

These records are required so that the FreeIPA server can find the AD servers? 

Also, is it fair to infer that Default-First-Site-Name is in our case co.org.au?

Cheers
L.
This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been 
intercepted or altered and will not be liable for any delay 
in its receipt.


-- 
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] IPA wont start, all services fail

2016-01-20 Thread Simpson Lachlan
> -Original Message-
> From: Simpson Lachlan
 
> I would like to test a few things, but I'm finding it hard to find good 
> examples.
> 
>  How can I test that the one way trust relationship between the FreeIPA server
>and the AD DC is still in effect? (FreeIPA trusts AD, AD does not trust
> FreeIIPA).
>I presume there is an ldapsearch or sssd command that should connect 
> directly
> to
>the AD server?

I should have asked for what I wanted, because of course I found the solution 
to what 
I *did* ask almost immediately.

Real question: If I get the SID for the "SMB Default Group", is it just a 
matter of editing 
the ldap directory via ldapmodify?

No, because that's again not the issue.

The samba error I get is

pdb backend ipasam:ldapi://%2fvar%2frun%2fslapd-UNIX-CO-ORG-AU.socket did not 
correctly init (error was NT_STATUS_INVALID_PARAMETER)

pbdedit fails on the same problem. 

How can I set the SID of the default group manually - by which I mean, using a 
command line tool to manipulate text (rather than a shell script or 
ipa-adtrust).

Cheers
L.
This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been 
intercepted or altered and will not be liable for any delay 
in its receipt.


-- 
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] IPA wont start, all services fail

2016-01-20 Thread Simpson Lachlan

> -Original Message-
> From: Alexander Bokovoy [mailto:aboko...@redhat.com]
> Sent: Thursday, 21 January 2016 9:22 AM

> >ses=4294967295 subj=kernel pid=18340 comm="httpd" reason="memory
> >violation" sig=11 type=ANOM_ABEND msg=audit(1453325558.988:1245):
> >auid=4294967295 uid=991 gid=987 ses=4294967295 subj=kernel pid=18357
> >comm="httpd" reason="memory violation" sig=11
> Ok, I see two problems above and they may be related to recently fixed issue 
> with
> python-cryptography's use of python-cffi. However, this issue should not 
> affect
> CentOS 7.2 as the broken python-cryptography code is not in RHEL 7.2 at all, 
> so
> I'm a bit puzzled.


I’m sure it's now apparent that I'm a relative FreeIPA/sssd new comer, and tbh, 
my 
involvement with AD has been "enough to not hurt myself or others or 
production",
samba I last played with seriously for AD related issues way back when 2.x was 
around - since then it's been file sharing only.

I would like to test a few things, but I'm finding it hard to find good 
examples.

 How can I test that the one way trust relationship between the FreeIPA server
   and the AD DC is still in effect? (FreeIPA trusts AD, AD does not trust 
FreeIIPA).
   I presume there is an ldapsearch or sssd command that should connect 
directly to
   the AD server? 

Cheers
L.
This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been 
intercepted or altered and will not be liable for any delay 
in its receipt.


-- 
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] IPA wont start, all services fail

2016-01-20 Thread Simpson Lachlan
> -Original Message-
> 
> Is there any coredump available with 389-ds crashing? I've asked you to use
> http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes to enable
> coredumps for 389-ds in one of previous discussions, was it done?
> You seemed to get diverted to winbindd core (which was expected to coredump as
> 389-ds was not available), but if you see 389-ds disappearing in several hours
> without any logging, this means there was a crash and we'd like to see the
> coredump of it.

Hi Alex,

I did perform the "Debugging Crashes" steps when you asked, but there are still 
no core dumps in /var/log/dirsrv/slapd-INSTANCENAME.

 
> You can check also /var/log/audit/audit.log to see if there is a trace of a 
> crash. It
> may take different ways but one crash type is following:
 
> type=ANOM_ABEND msg=audit(1453212583.746:2337): auid=4294967295
> uid=983
> gid=980 ses=4294967295 subj=system_u:system_r:dirsrv_t:s0 pid=26079
> comm="ns-slapd" exe="/usr/sbin/ns-slapd" sig=11

There are no instances of ns-slap in the audit.log, there are a dozen sig=11s, 
all of them relate to a "memory violation" in httpd_t, and all references to 
dirsrv look like this:

type=SERVICE_STOP msg=audit(1453174960.933:209): pid=1 uid=0 auid=4294967295 
ses=4294967295 subj=kernel msg='unit=dirsrv@UNIX-CO-ORG-AU comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'


cheers
L.  
This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been 
intercepted or altered and will not be liable for any delay 
in its receipt.


-- 
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] IPA wont start, all services fail

2016-01-20 Thread Simpson Lachlan
> -Original Message-
> From: Alexander Bokovoy [mailto:aboko...@redhat.com]
> Sent: Thursday, 21 January 2016 9:22 AM
> To: Simpson Lachlan
> Cc: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] IPA wont start, all services fail
> 
> On Wed, 20 Jan 2016, Simpson Lachlan wrote:
> >> -Original Message-
> >> From: Alexander Bokovoy [mailto:aboko...@redhat.com]
> >> Sent: Thursday, 21 January 2016 8:44 AM
> >> To: Simpson Lachlan
> >> Cc: tbor...@redhat.com; freeipa-users@redhat.com
> >> Subject: Re: [Freeipa-users] IPA wont start, all services fail
> >>
> >> On Wed, 20 Jan 2016, Simpson Lachlan wrote:
> >> >> -Original Message-
> >> >>
> >> >> Is there any coredump available with 389-ds crashing? I've asked
> >> >> you to use
> >> >> http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes
> >> >> to
> >> enable coredumps for 389-ds in one of previous discussions, was it done?
> >> >> You seemed to get diverted to winbindd core (which was expected to
> >> >> coredump as 389-ds was not available), but if you see 389-ds
> >> >> disappearing in several hours without any logging, this means
> >> >> there was a crash and we'd like to see the coredump of it.
> >> >
> >> >Hi Alex,
> >> >
> >> >I did perform the "Debugging Crashes" steps when you asked, but
> >> >there are still no core dumps in /var/log/dirsrv/slapd-INSTANCENAME.
> >> Well, perhaps it takes longer to get a crash than what you are expecting.
> >>
> >> >> You can check also /var/log/audit/audit.log to see if there is a
> >> >> trace of a crash. It may take different ways but one crash type is 
> >> >> following:
> >> >
> >> >> type=ANOM_ABEND msg=audit(1453212583.746:2337): auid=4294967295
> >> >> uid=983
> >> >> gid=980 ses=4294967295 subj=system_u:system_r:dirsrv_t:s0
> >> >> pid=26079 comm="ns-slapd" exe="/usr/sbin/ns-slapd" sig=11
> >> >
> >> >There are no instances of ns-slap in the audit.log, there are a
> >> >dozen sig=11s, all of them relate to a "memory violation" in
> >> >httpd_t, and all references to dirsrv look like this:
> >> >
> >> >type=SERVICE_STOP msg=audit(1453174960.933:209): pid=1 uid=0
> >> >auid=4294967295 ses=4294967295 subj=kernel
> >> >msg='unit=dirsrv@UNIX-CO-ORG-AU comm="systemd"
> >> >exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=?
> >> >res=success'
> >> What are the memory violation for httpd_t? Can you show exact line
> >> from audit.log?
> >
> >
> >
> >type=ANOM_ABEND msg=audit(1452818553.235:5394): auid=4294967295
> uid=48
> >gid=48 ses=4294967295 subj=system_u:system_r:httpd_t:s0 pid=32704
> >comm="httpd" reason="memory violation" sig=11 type=ANOM_ABEND
> Ok, I see two problems above and they may be related to recently fixed issue 
> with
> python-cryptography's use of python-cffi. However, this issue should not 
> affect
> CentOS 7.2 as the broken python-cryptography code is not in RHEL 7.2 at all, 
> so
> I'm a bit puzzled.

Me too. I can't even give SIDs to the smb default group with 
ipa-adtrust-install --add-sids (as mentioned in another email thread this 
morning). 

I tried this bc it reflects an obvious solution to the problem I seem to have? 
That everything starts except smb, and ipa also fails as a result of smb 
failing.


Smb fails with the error 

smbd[18615]: [2016/01/21 08:32:37.519517,  0] 
ipa_sam.c:3654(get_fallback_group_sid)
smbd[18615]:   Missing mandatory attribute ipaNTSecurityIdentifier.
smbd[18615]: [2016/01/21 08:32:37.519572,  0] ipa_sam.c:4606(pdb_init_ipasam)
smbd[18615]:   Cannot find SID of fallback group.
smbd[18615]: [2016/01/21 08:32:37.519593,  0] 
../source3/passdb/pdb_interface.c:179(make_pdb_method_name)
smbd[18615]:   pdb backend 
ipasam:ldapi://%2fvar%2frun%2fslapd-UNIX-CO-ORG-AU.socket did not correctly 
init (error was NT_STATUS_INVALID_PARAMETER)
systemd[1]: smb.service: main process exited, code=exited, status=1/FAILURE
systemd[1]: Failed to start Samba SMB Daemon.


I know I keep coming back to this, but it really does seem to be the error that 
I am seeing most often.

Cheers
L.
This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been 
intercepted or altered and will not be liable for any delay 
in its receipt.


-- 
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] IPA wont start, all services fail

2016-01-20 Thread Simpson Lachlan
> -Original Message-
> From: Alexander Bokovoy [mailto:aboko...@redhat.com]
> Sent: Thursday, 21 January 2016 8:44 AM
> To: Simpson Lachlan
> Cc: tbor...@redhat.com; freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] IPA wont start, all services fail
> 
> On Wed, 20 Jan 2016, Simpson Lachlan wrote:
> >> -Original Message-
> >>
> >> Is there any coredump available with 389-ds crashing? I've asked you
> >> to use
> >> http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes to
> enable coredumps for 389-ds in one of previous discussions, was it done?
> >> You seemed to get diverted to winbindd core (which was expected to
> >> coredump as 389-ds was not available), but if you see 389-ds
> >> disappearing in several hours without any logging, this means there
> >> was a crash and we'd like to see the coredump of it.
> >
> >Hi Alex,
> >
> >I did perform the "Debugging Crashes" steps when you asked, but there
> >are still no core dumps in /var/log/dirsrv/slapd-INSTANCENAME.
> Well, perhaps it takes longer to get a crash than what you are expecting.
> 
> >> You can check also /var/log/audit/audit.log to see if there is a
> >> trace of a crash. It may take different ways but one crash type is 
> >> following:
> >
> >> type=ANOM_ABEND msg=audit(1453212583.746:2337): auid=4294967295
> >> uid=983
> >> gid=980 ses=4294967295 subj=system_u:system_r:dirsrv_t:s0 pid=26079
> >> comm="ns-slapd" exe="/usr/sbin/ns-slapd" sig=11
> >
> >There are no instances of ns-slap in the audit.log, there are a dozen
> >sig=11s, all of them relate to a "memory violation" in httpd_t, and all
> >references to dirsrv look like this:
> >
> >type=SERVICE_STOP msg=audit(1453174960.933:209): pid=1 uid=0
> >auid=4294967295 ses=4294967295 subj=kernel
> >msg='unit=dirsrv@UNIX-CO-ORG-AU comm="systemd"
> >exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=?
> >res=success'
> What are the memory violation for httpd_t? Can you show exact line from
> audit.log?



type=ANOM_ABEND msg=audit(1452818553.235:5394): auid=4294967295 uid=48 gid=48 
ses=4294967295 subj=system_u:system_r:httpd_t:s0 pid=32704 comm="httpd" 
reason="memory violation" sig=11
type=ANOM_ABEND msg=audit(1452818553.258:5395): auid=4294967295 uid=48 gid=48 
ses=4294967295 subj=system_u:system_r:httpd_t:s0 pid=32707 comm="httpd" 
reason="memory violation" sig=11
type=ANOM_ABEND msg=audit(1452962463.319:1390): auid=4294967295 uid=991 gid=987 
ses=4294967295 subj=kernel pid=12939 comm="httpd" reason="memory violation" 
sig=11
type=ANOM_ABEND msg=audit(1453071013.594:2471): auid=0 uid=0 gid=0 ses=202 
subj=kernel pid=17888 comm="systemd-tty-ask" reason="memory violation" sig=11
type=ANOM_ABEND msg=audit(1453161444.878:732): auid=4294967295 uid=48 gid=48 
ses=4294967295 subj=kernel pid=15219 comm="httpd" reason="memory violation" 
sig=11
type=ANOM_ABEND msg=audit(1453162831.092:807): auid=4294967295 uid=991 gid=987 
ses=4294967295 subj=kernel pid=17619 comm="httpd" reason="memory violation" 
sig=11
type=ANOM_ABEND msg=audit(1453167608.043:869): auid=4294967295 uid=48 gid=48 
ses=4294967295 subj=kernel pid=19188 comm="httpd" reason="memory violation" 
sig=11
type=ANOM_ABEND msg=audit(1453167608.281:870): auid=4294967295 uid=48 gid=48 
ses=4294967295 subj=kernel pid=19191 comm="httpd" reason="memory violation" 
sig=11
type=ANOM_ABEND msg=audit(1453174424.305:167): auid=4294967295 uid=48 gid=48 
ses=4294967295 subj=kernel pid=13075 comm="httpd" reason="memory violation" 
sig=11
type=ANOM_ABEND msg=audit(1453174424.337:168): auid=4294967295 uid=48 gid=48 
ses=4294967295 subj=kernel pid=13078 comm="httpd" reason="memory violation" 
sig=11
type=ANOM_ABEND msg=audit(1453174959.183:205): auid=4294967295 uid=991 gid=987 
ses=4294967295 subj=kernel pid=14220 comm="httpd" reason="memory violation" 
sig=11
type=ANOM_ABEND msg=audit(1453174959.183:206): auid=4294967295 uid=991 gid=987 
ses=4294967295 subj=kernel pid=14203 comm="httpd" reason="memory violation" 
sig=11
type=ANOM_ABEND msg=audit(1453325222.755:1226): auid=4294967295 uid=48 gid=48 
ses=4294967295 subj=kernel pid=14716 comm="httpd" reason="memory violation" 
sig=11
type=ANOM_ABEND msg=audit(1453325222.825:1227): auid=4294967295 uid=48 gid=48 
ses=4294967295 subj=kernel pid=14713 comm="httpd" reason="memory violation" 
sig=11
type=ANOM_ABEND msg=audit(1453325558.988:1244): auid=4294967295 u

Re: [Freeipa-users] IPA wont start, all services fail

2016-01-19 Thread Simpson Lachlan
> -Original Message-

> From: Alexander Bokovoy [mailto:aboko...@redhat.com]
> Let's start from the beginning:
> 
>  - What distribution you are running?

Centos, Linux release 7.2.1511 (Core)


>  - What IPA packages are installed?

[root@vmts-linuxidm ~]# yum list installed | grep ipa
ipa-admintools.x86_64  4.2.0-15.el7.centos.3   @updates 
ipa-client.x86_64  4.2.0-15.el7.centos.3   @updates 
ipa-python.x86_64  4.2.0-15.el7.centos.3   @updates 
ipa-server.x86_64  4.2.0-15.el7.centos.3   @updates 
ipa-server-dns.x86_64  4.2.0-15.el7.centos.3   @updates 
ipa-server-trust-ad.x86_64 4.2.0-15.el7.centos.3   @updates 
libipa_hbac.x86_64 1.13.0-40.el7_2.1   @updates 
python-iniparse.noarch 0.4-9.el7   @anaconda
python-libipa_hbac.x86_64  1.13.0-40.el7_2.1   @updates 
sssd-ipa.x86_641.13.0-40.el7_2.1   @updates

>  - What 389-ds-base package is installed?

[root@vmts-linuxidm ~]# yum list installed | grep 389
389-admin.x86_64   1.1.38-1.el7@epel
389-adminutil.x86_64   1.1.21-2.el7@epel
389-adminutil-devel.x86_64 1.1.21-2.el7@epel
389-ds-base.x86_64 1.3.4.0-21.el7_2@updates 
389-ds-base-debuginfo.x86_64   1.3.4.0-21.el7_2
@base-debuginfo
389-ds-base-libs.x86_641.3.4.0-21.el7_2@updates


>  - What slapi-nis package is installed?

slapi-nis.x86_64   0.54-6.el7_2@updates


> It looks like if things are working for "few hours" and then stop, this means 
> 389-ds
> did crash somehow. There were several cases where it might crash but they were
> fixed and latest releases have no known crashes, either with RHEL 6.7 or RHEL
> 7.2 and their off-springs.


Cheers
L.
This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been 
intercepted or altered and will not be liable for any delay 
in its receipt.


-- 
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] IPA wont start, all services fail

2016-01-18 Thread Simpson Lachlan
> -Original Message-
> From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-


I’m coming back to this thread for consistency, but is a result of me running 
ipactl on the system we got working a couple of hours ago. See email titled 
"idoverride-add gives incorrect, inconsistant results?" for leadup.

Anyway, ipactl restart fails, again.


[root@vmts-linuxidm ~]# ipactl restart
Stopping pki-tomcatd Service
Restarting Directory Service
Restarting krb5kdc Service
Restarting kadmin Service
Restarting ipa_memcached Service
Restarting httpd Service
Restarting pki-tomcatd Service
inconsistRestarting winbind Service
Restarting ipa-otpd Service
Starting smb Service
Job for smb.service failed because the control process exited with error code. 
See "systemctl status smb.service" and "journalctl -xe" for details.
Failed to start smb Service
Shutting down
Aborting ipactl


Gah. Look in the samba log, and it's exactly the same issue.

Right.

[root@vmts-linuxidm ~]# ipa-adtrust-install --netbios-name=UNIX -a xxx

The log file for this installation can be found in 
/var/log/ipaserver-install.log
==
This program will setup components needed to establish trust to AD domains for
the IPA Server.

This includes:
  * Configure Samba
  * Add trust related objects to IPA LDAP server

To accept the default shown in brackets, press the Enter key.

IPA generated smb.conf detected.
Overwrite smb.conf? [no]: yes
Do you want to enable support for trusted domains in Schema Compatibility 
plugin?
This will allow clients older than SSSD 1.9 and non-Linux clients to work with 
trusted users.

Enable trusted domains support in slapi-nis? [no]: yes

There was error to automatically re-kinit your admin user ticket.
Proceeding with credentials that existed before
Outdated Kerberos credentials. Use kdestroy and kinit to update your ticket

Huh?

[root@vmts-linuxidm ~]# kdestroy
[root@vmts-linuxidm ~]# kinit admin
kinit: Cannot contact any KDC for realm 'UNIX.CO.ORG.AU' while getting initial 
credentials

I check, and sure enough, dir...@unix.co.org.au has stopped again (should I 
call it 389, dirsrv, ldap or slapd? They are all the same thing, right?).

I restart dirsrv, and try restarting smb, no joy. I try running 
ipa-adtrust-install again, without luck. I restart krb5kdc manually (sc start 
krb5kdc), and try all the above again, with no luck. 

kdestroy has a lovely little pause, but kinit admin fails.

Some of the other errors I've received:

ipa-adtrust-install

There was error to automatically re-kinit your admin user ticket.
Proceeding with credentials that existed before
Must have Kerberos credentials to setup AD trusts on serve

klist
klist: Credentials cache keyring 'persistent:0:0' not found


Ok, so I try sc start krb5kdc and that works. Now klist still returns the above 
error, but kinit admin works. And ipa-adtrust-install works as it did this AM 
(output at end for reference).

FWIW:

 - I can now browse the IPA server via a web browser.
 - I can retrieve credentials for those that I've already retrieved credentials 
for (id testu...@co.org.au works)
 - I can't retrieve new credentials (id testuser_...@co.org.au does not work 
("no such user")
 - if I sc --failed:

  UNITLOAD  ACTIVE SUBDESCRIPTION
● ipa.service loadedfailed failed Identity, Policy, Audit
● kadmin.service  loadedfailed failed Kerberos 5 Password-changing and 
Administration
● smb.service loadedfailed failed Samba SMB Daemon

 - None of these will start on their own (with sc start .service)
 - trying to start ipa fails with the added bonus of shutting down krb5kdc / 
kadmin / dir...@domain.org.au as well? I'm finding I'm needing to restart these 
services after attempting an ipa start. Which is failing on smb still. 
 - krb5kdc also doesn't start.

I am so confused. Earlier in the day when it was "working", I noticed that 
there was a service running called ipa.memchached - I presume that's why I can 
get some id's and not others and can browse via web (well, that just means 
tomcat started correctly, right?). ipa.memcached has disappeared from the list 
of running services when I sc now. 


So. How can I create a situation where when I restart ipa, for whatever reason, 
this doesn't happen again?

Secondary question: given that I have missed something seemingly integral, is 
there a document that describes the post install setup process I should go 
through to stop this error from re-occurring?

Cheers
L.




Notes:
root@vmts-linuxidm ~]# ipa-adtrust-install --netbios-name=UNIX -a xxx

The log file for this installation can be found in 
/var/log/ipaserver-install.log
==
This program will setup components needed to establish trust to AD domains for
the IPA Server.

This includes:
  * Configure Samba
  * Add trust related objects to IPA LDAP 

[Freeipa-users] idoverride-add gives incorrect, inconsistant results?

2016-01-18 Thread Simpson Lachlan
Since I got the service back up and running, I was continuing my tests/learning 
by following the steps on the V4 Migrating existing environments to Trust page:

http://www.freeipa.org/page/V4/Migrating_existing_environments_to_Trust#How_to_Test



[root@vmts-linuxidm ~]# id testu...@co.org.au
uid=1750693931(testu...@co.org.au) gid=1750693931(testu...@co.org.au) 
groups=1750693931(testu...@co.org.au),1750687326(bioinf-st...@co.org.au)


Success and joy.


[root@vmts-linuxidm ~]# ipa idoverrideuser-add 'Default Trust View' 
testu...@co.org.au --uid 1506
---
Added User ID override "testu...@co.org.au"
---
  Anchor to override: testu...@co.org.au
  UID: 1506



Great.


[root@vmts-linuxidm ~]# sudo systemctl restart sssd 

[root@vmts-linuxidm ~]# id testu...@co.org.au
uid=1750693931(testu...@co.org.au) gid=1750693931(testu...@co.org.au) 
groups=1750693931(testu...@co.org.au),1750687326(bioinf-st...@co.org.au)


Huh? The documentation linked to above says that uid should now be 1506?

I went searching in the website - took me a while to find it, but it was there 
- see attached image. The uid had been updated *somewhere*, but the id command 
wasn't seeing it.

Maybe a full ipa restart would help?

Ipactl restart

And samba is failing again. Ouch. Brb.

L.




This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been 
intercepted or altered and will not be liable for any delay 
in its receipt.

-- 
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] IPA wont start, all services fail

2016-01-18 Thread Simpson Lachlan
> -Original Message-
> From: Simpson Lachlan


I've rebooted the machine, confirmed that FreeIPA isn't functioning (nothing
in the browser, nothing in sc).

I run

sc start dirsrv@UNIX-CO-ORG-AU.service
ipactl start

Starting Directory Service
Starting krb5kdc Service
Starting kadmin Service
Starting ipa_memcached Service
Starting httpd Service
Starting pki-tomcatd Service
Starting smb Service
Job for smb.service failed because the control process exited with error
code. See "systemctl status smb.service" and "journalctl -xe" for details.
Failed to start smb Service
Shutting down
Aborting ipactl


The samba problem again, great. We know how to fix that.

ipa-adtrust-install --netbios-name=UNIX

Finishes successfully.

Browser doesn't work, cli doesn't work, nothing works.

OK.

I run this list of commands successfully:

ipctl stop
sc start dirsrv@UNIX-CO-ORG-AU.service
sc start krb5kdc
sc start kadmin
kdestroy
kinit admin
sc start ipa_memcached
sc start httpd
sc restart pki-tomcatd.target
ipa-adtrust-install --netbios-name=UNIX


sc --failed shows:
- ipa.service loaded failed failed Identity, Policy, Audit
- smb.service loaded failed failed Samba SMB Daemon

An attempt to start smb fails as per ipaNTSecurityIdentifier error that I got 
yesterday.
An attempt to start ipa manually (sc start ipa) fails as per above, but also
brings down all working services, requiring that they be restarted manually if
needed for future testing.

Final note. When I run ipa-adtrust-install --netbios-name=UNIX I get what
looks like a success message, although the output contains the following,
neither of which I can fully understand:

DNS management was not enabled at install time.
Add the following service records to your DNS server for DNS zone
unix.co.org.au:
 - _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs
 - _ldap._tcp.dc._msdcs
 - _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs
 - _kerberos._tcp.dc._msdcs
 - _kerberos._udp.Default-First-Site-Name._sites.dc._msdcs
 - _kerberos._udp.dc._msdcs


(my unix.co.org.au DNS is managed upstream by the AD PDC, presumably this
is dealt with?)

and

 [22/23]: starting CIFS services
ipa : CRITICAL CIFS services failed to start
  [23/23]: adding SIDs to existing users and groups
Done configuring CIFS.

(no idea?)


Cheers
L.

This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been 
intercepted or altered and will not be liable for any delay 
in its receipt.


-- 
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] IPA wont start, all services fail

2016-01-18 Thread Simpson Lachlan
> -Original Message-
> From: Alexander Bokovoy [mailto:aboko...@redhat.com]
> This error says you don't have 'Default SMB Group' with a SID in it.
> Re-run ipa-adtrust-install to re-create working setup.
> 
> ipa-adtrust-install will attempt to fix those parts that are missing.


Ok. I have web access. Thank you for your help!

Cheers
L.
This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been 
intercepted or altered and will not be liable for any delay 
in its receipt.


-- 
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] IPA wont start, all services fail

2016-01-18 Thread Simpson Lachlan
> -Original Message-
> From: Simpson Lachlan
> Sent: Tuesday, 19 January 2016 9:46 AM
> To: 'Alexander Bokovoy'
> Cc: freeipa-users@redhat.com
> Subject: RE: [Freeipa-users] IPA wont start, all services fail
> 
> > -Original Message-
> > From: Alexander Bokovoy [mailto:aboko...@redhat.com] This error says
> > you don't have 'Default SMB Group' with a SID in it.
> > Re-run ipa-adtrust-install to re-create working setup.
> >
> > ipa-adtrust-install will attempt to fix those parts that are missing.
> 
> 
> Ok. I have web access. Thank you for your help!

By which I mean, it all seems to be working now.

Thanks.

L.  
This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been 
intercepted or altered and will not be liable for any delay 
in its receipt.


-- 
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] IPA wont start, all services fail

2016-01-18 Thread Simpson Lachlan
> -Original Message-
> From: Alexander Bokovoy [mailto:aboko...@redhat.com]
> > - /etc/nsswitch.conf is all "files sss" - there's no winbind anywhere.
> winbindd has multiple operations and we are using trust topology part of it, 
> not
> identity management.

Ok, thanks. 

> >My syntax was all wrong. (Does anyone know how can I clear out bad
> >syntax from the systemctld output?)
> what bad output?

It's ok, systemctl has cleaned itself up.


>  systemctl start dirsrv@INSTANCE
> is the correct syntax where INSTANCE is the same for /etc/dirsrv/slapd-
> INSTANCE or /var/log/dirsrv/slapd-INSTANCE.
> The name of instance is produced from the realm by replacing dots with -.

Yep, as I discovered.
 
> So, start KDC.
> 
> You can at this point simply try 'ipactl restart' -- it will attempt to 
> shutdown and
> restart all required IPA services, including KDC.

First thing I did this AM. Still fails on samba:


[root@vmts-linuxidm ~]# ipactl restart
Starting Directory Service
Starting krb5kdc Service
Starting kadmin Service
Starting ipa_memcached Service
Starting httpd Service
Starting pki-tomcatd Service
Starting smb Service
Job for smb.service failed because the control process exited with error code. 
See "systemctl status smb.service" and "journalctl -xe" for details.
Failed to start smb Service
Shutting down
Aborting ipactl

[root@vmts-linuxidm ~]# systemctl status smb.service -l
● smb.service - Samba SMB Daemon
   Loaded: loaded (/usr/lib/systemd/system/smb.service; disabled; vendor 
preset: disabled)
   Active: failed (Result: exit-code) since Tue 2016-01-19 08:20:14 AEDT; 43s 
ago
  Process: 14240 ExecStart=/usr/sbin/smbd $SMBDOPTIONS (code=exited, 
status=1/FAILURE)
 Main PID: 14240 (code=exited, status=1/FAILURE)
   Status: "Starting process..."

smbd[14240]: [2016/01/19 08:20:14.288659,  0] 
ipa_sam.c:3654(get_fallback_group_sid)
smbd[14240]:   Missing mandatory attribute ipaNTSecurityIdentifier.
smbd[14240]: [2016/01/19 08:20:14.288716,  0] ipa_sam.c:4606(pdb_init_ipasam)
smbd[14240]:   Cannot find SID of fallback group.
smbd[14240]: [2016/01/19 08:20:14.288734,  0] 
../source3/passdb/pdb_interface.c:179(make_pdb_method_name)
smbd[14240]:   pdb backend 
ipasam:ldapi://%2fvar%2frun%2fslapd-UNIX-co-ORG-AU.socket did not correctly 
init (error was NT_STATUS_INVALID_PARAMETER)
systemd[1]: smb.service: main process exited, code=exited, status=1/FAILURE
systemd[1]: Failed to start Samba SMB Daemon.
systemd[1]: Unit smb.service entered failed state.
systemd[1]: smb.service failed.


Same error as previously:

[2016/01/19 08:26:31,  0] ../source3/smbd/server.c:1241(main)
  smbd version 4.2.3 started.
  Copyright Andrew Tridgell and the Samba Team 1992-2014
[2016/01/19 08:26:32.037071,  0] ipa_sam.c:3654(get_fallback_group_sid)
  Missing mandatory attribute ipaNTSecurityIdentifier.
[2016/01/19 08:26:32.037122,  0] ipa_sam.c:4606(pdb_init_ipasam)
  Cannot find SID of fallback group.
[2016/01/19 08:26:32.037140,  0] 
../source3/passdb/pdb_interface.c:179(make_pdb_method_name)
  pdb backend ipasam:ldapi://%2fvar%2frun%2fslapd-UNIX-CO-ORG-AU.socket did not 
correctly init (error was NT_STATUS_INVALID_PARAMETER)


My reading is that I haven't got the SIDs properly aligned for any user 
(including the admin user set up when installing freeipa) since joining the 
domain, and samba is failing on that. Can I retrospectively add SIDs to an 
entry?

Cheers
L.


This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been 
intercepted or altered and will not be liable for any delay 
in its receipt.


-- 
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] IPA wont start, all services fail

2016-01-17 Thread Simpson Lachlan
> -Original Message-
> 
> My syntax was all wrong. (Does anyone know how can I clear out bad syntax from
> the systemctld output?)
> 
> Anyway, I have a running dirsrv, but SMB still fails, and it's failing on 
> winbind first
> (see notes below). It looks like it's because there's no Kerberos server 
> available.
> Indeed, kinit admin is still failing. I think that when I ran 
> ipa-adtrust-install I said no
> to creating sids for local users.
> 
> I'm beginning to think that is the root error, but have a feeling that 
> winbind isn't
> helping either.
> 
> 
> Does this seem more likely?


After some more work on this, I see from this documentation that winbind is 
required:

http://www.freeipa.org/page/Active_Directory_trust_setup#Edit_.2Fetc.2Fkrb5.conf

(although we are only using one way trusts - does that change anything?)


Also, after getting a lot of errors that looked like

krb5kdc: cannot initialize realm UNIX.CO.ORG.AU - see log file for details

Server error - while fetching master key K/M for realm UNIX.CO.ORG.AU

I thought maybe it was because I'd created the realm with lower case - I had a 
file /var/kerberos/krb5kdc/.k5.unix.co.org.au

So I tried destroying that and creating a UNIX.CO.ORG.AU although now I have a 
new problem - 

add_principal: Kerberos database constraints violated while creating 
UNIX.CO.ORG.AU

I discover that I'm meant to use ipa service-add (I presume 
cifs/UNIX.CO.ORG.AU), but that fails bc no Kerberos credentials.

Now everything I google takes me, essentially, to the "install ipa" page.

Should I just run ipa-server-install and  ipa-adtrust-install again? Does that 
re-write all the important things? Or should I yum remove, then yum install 
again? (if this is the solution I should try)

Cheers
L.



This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been 
intercepted or altered and will not be liable for any delay 
in its receipt.


-- 
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] IPA wont start, all services fail

2016-01-17 Thread Simpson Lachlan
> -Original Message-
> From: Alexander Bokovoy [mailto:aboko...@redhat.com]
> >This is from the smb log:
> >
> >It's hard to tell why they won't start, but it looks a little like
> >Kerberos won't start because there aren't any values in LDAP, and LDAP
> >won't start because Kerberos isn't started?
> No, LDAP server startup is not tied to Kerberos. It can perfectly start 
> without that,
> as Kerberos in 389-ds is only needed for replication to happen.

Great - thanks.

 
> Samba is failing because it cannot get access to LDAP server using GSSAPI,
> that's right.
> 
> KDC is failing because LDAP server is not available, that's right too.
> ... 
> You may ignore ACL's plugin output as it just mentions that there are ACLs
> against entries which don't exist -- this is normal, because we still have 
> ACLs in
> place for cn=dns,$SUFFIX even if you don't configure integrated DNS. These
> messages have nothing to do with your problem.

ok, thanks.

> None of the above is revealing an issue.
> 
> Follow http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes
> to enable crashdumps for ns-slapd to see what happens in reality (check
> systemd-enabled systems' recipes).

Here is where things got interesting - I was 20 minutes in before I realised I 
had 
no dirsrv core dumps.

New things I learnt while doing this though:

 - I have 2.5 GB of core files in /var/log/samba/cores/winbindd ? To the best 
of my 
knowledge I was using SSSD, I have no idea what winbind is doing there. Can I 
just 
delete (yum remove samba-winbind*) it? From the look of it, I'm getting a new 
winbind 
core dump every 5 minutes.Could this be stopping samba from running?

 - /etc/nsswitch.conf is all "files sss" - there's no winbind anywhere.

- while following the instructions to "set ulimit -c unlimited" on system I 
found things 
that *really* confused me:

As noted in the original email, this was in the failed list of systemctld:

 dir...@unix.co.org.au.service

and it continues to fail this morning. So I tried running 

sc start dirsrv.target

and that worked:

[root@vmts-linuxidm samba]# sc status dirsrv.target
● dirsrv.target - 389 Directory Server
   Loaded: loaded (/usr/lib/systemd/system/dirsrv.target; enabled; vendor 
preset: disabled)
   Active: active since Mon 2016-01-18 09:58:14 AEDT; 1h 20min ago

Jan 18 09:58:14 vmts-linuxidm.unix.co.org.au systemd[1]: Reached target 389 
Directory Server.
Jan 18 09:58:14 vmts-linuxidm.unix.co.org.au systemd[1]: Starting 389 Directory 
Server.



So I stopped it and started dir...@unix.co.org.au just to confirm, and yes it's 
failing. 
After some testing, I discovered that *this* would work:

sc start dirsrv@UNIX-CO-ORG-AU

My syntax was all wrong. (Does anyone know how can I clear out bad syntax from 
the 
systemctld output?)

Anyway, I have a running dirsrv, but SMB still fails, and it's failing on 
winbind first (see 
notes below). It looks like it's because there's no Kerberos server available. 
Indeed, 
kinit admin is still failing. I think that when I ran ipa-adtrust-install I 
said no to creating 
sids for local users. 

I'm beginning to think that is the root error, but have a feeling that winbind 
isn't helping 
either.


Does this seem more likely?

Cheers
L.




Notes:

Running DIRSRV 

[root@vmts-linuxidm samba]# sc status dirsrv@UNIX-CO-ORG-AU.service
● dirsrv@UNIX-CO-ORG-AU.service - 389 Directory Server UNIX-CO-ORG-AU.
   Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; enabled; vendor 
preset: disabled)
   Active: active (running) since Mon 2016-01-18 11:21:25 AEDT; 5min ago
  Process: 11655 ExecStart=/usr/sbin/ns-slapd -D /etc/dirsrv/slapd-%i -i 
/var/run/dirsrv/slapd-%i.pid -w /var/run/dirsrv/slapd-%i.startpid (code=exited, 
status=0/SUCCESS)
 Main PID: 11656 (ns-slapd)
   CGroup: /system.slice/system-dirsrv.slice/dirsrv@UNIX-CO-ORG-AU.service
   └─11656 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-UNIX-CO-ORG-AU -i 
/var/run/dirsrv/slapd-UNIX-CO-OR...

Jan 18 11:21:25 vmts-linuxidm.unix.co.org.au ns-slapd[11655]: 
[18/Jan/2016:11:21:25 +1100] - SSL alert: ...led
Jan 18 11:21:25 vmts-linuxidm.unix.co.org.au ns-slapd[11655]: 
[18/Jan/2016:11:21:25 +1100] - SSL alert: ...led
Jan 18 11:21:25 vmts-linuxidm.unix.co.org.au ns-slapd[11655]: 
[18/Jan/2016:11:21:25 +1100] - SSL alert: ...led
Jan 18 11:21:25 vmts-linuxidm.unix.co.org.au ns-slapd[11655]: 
[18/Jan/2016:11:21:25 +1100] - SSL alert: ...led
Jan 18 11:21:25 vmts-linuxidm.unix.co.org.au ns-slapd[11655]: 
[18/Jan/2016:11:21:25 +1100] - SSL alert: ...led
Jan 18 11:21:25 vmts-linuxidm.unix.co.org.au ns-slapd[11655]: 
[18/Jan/2016:11:21:25 +1100] - SSL alert: ...led
Jan 18 11:21:25 vmts-linuxidm.unix.co.org.au ns-slapd[11655]: 
[18/Jan/2016:11:21:25 +1100] SSL Initialization - ...1.2
Jan 18 11:25:06 vmts-linuxidm.unix.co.org.au ns-slapd[11656]: GSSAPI server 
step 1
Jan 18 11:25:06 vmts-linuxidm.unix.co.org.au ns-slapd[11656]: GSSAPI server 
step 2
Jan 

[Freeipa-users] IPA wont start, all services fail

2016-01-14 Thread Simpson Lachlan
Hi

I’m not 100% sure where I've gone wrong, but I obviously have.

Running Centos 7.2, with FreeIPA 4.2.0 from the repos.

FreeIPA was set up per instructions (# ipa-server-install ), and we could surf 
to the website and interact with it. 

I set up a second server, yum install -y ipa-client, and then joined with 
authconfig successfully and logged in.

Our intention is to join an AD domain over which we have no control in a one 
way trust: co.org.au is trusted by unix.co.org.au.

In order to do this, I followed the instructions on redhat's documentation " 
5.3.3.1. Preparing the IdM Server for Trust"

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/creating-trusts.html#trust-set-up-idm

I installed "*ipa-server-trust-ad" samba, ran the ipa-adtrust-install script 
successfully, confirmed DNS was properly configured, confirmed smbclient was 
properly configured, then created a trust agreement successfully (this time 
yesterday I was cheering).


Added Active Directory trust for realm "co.org.au"

  Realm name: co.org.au
  Domain NetBIOS name: PMCI
  Domain Security Identifier: S-1-5-21-55386287-1424373824-1154838474
  SID blacklist incoming: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, 
S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, S-1-5-17, S-1-5-16, S-1-5-15, 
S-1-5-14, S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, S-1-1, S-1-0, 
S-1-5-19, S-1-5-18
  SID blacklist outgoing: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, 
S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, S-1-5-17, S-1-5-16, S-1-5-15, 
S-1-5-14, S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, S-1-1, S-1-0, 
S-1-5-19, S-1-5-18
  Trust direction: Trusting forest
  Trust type: Active Directory domain
  Trust status: Established and verified



Then I started to see some differentiation from the documented output, so I 
started investigating. In particular, kvno -S cifs adserver.example.com didn't 
work.

Eventually I turned off selinux and the firewall all together and rebooted. 

Now IPA doesn't start. When I look into it, this is what I see:


[root@vmts-linuxidm ~]# sc | grep failed
● dir...@unix.co.org.au.service  loaded failed failed389 Directory Server 
unix.co.org.au.
● ipa.service  loaded failed failedIdentity, 
Policy, Audit
● kadmin.service   loaded failed failedKerberos 5 
Password-changing and Administration
● kdump.serviceloaded failed failedCrash recovery 
kernel arming
● smb.service  loaded failed failedSamba SMB Daemon


>From the numerous logs and web pages I've read, I think this means:

IPA doesn't start because samba fails to start. 

This is from jouirnalctl re samba:

Missing mandatory attribute ipaNTSecurityIdentifier
Cannot find SID of fallback group
pdb backend ipasam:ldapi://%2fvar%2frun%2fslapd-UNIX-CO-ORG-AU.socket did not 
correctly init (error was NT_STATUS_INVALID_PARAMETER)
Server ldap/vmts-linux...@unix.co.org.au not found in Kerberos database


This is from the smb log:

[2016/01/15 14:53:03,  0] ../source3/smbd/server.c:1241(main)
  smbd version 4.2.3 started.
  Copyright Andrew Tridgell and the Samba Team 1992-2014
[2016/01/15 14:53:03.538393,  0] ipa_sam.c:4208(bind_callback_cleanup)
  kerberos error: code=-1765328228, message=Cannot contact any KDC for realm 
'UNIX.CO.ORG.AU'
[2016/01/15 14:53:03.538500,  0] 
../source3/lib/smbldap.c:998(smbldap_connect_system)
  failed to bind to server ldapi://%2fvar%2frun%2fslapd-UNIX-CO-ORG-AU.socket 
with dn="[Anonymous bind]" Error: Local error
(unknown)

Samba seems to be failing because LDAP (dirsrv) is failing and it can't 
connect, or because Kerberos isn't running.

LDAP isn't running because Kerberos isn't running:

krb5kdc: cannot initialize realm UNIX.CO.ORG.AU - see log file for details

krb5kdc: Server error - while fetching master key K/M for realm UNIX.CO.ORG.AU


So. It looks like samba and IPA won't start because Kerberus and LDAP won't 
start.

It's hard to tell why they won't start, but it looks a little like Kerberos 
won't start because there aren't any values in LDAP, and LDAP won't start 
because Kerberos isn't started?



This is from the /var/log/dirsrv/slapd-UNIX-CO-ORG-AU/errors file:

SSL Initialization - Configured SSL version range: min: TLS1.0, max: TLS1.2
- 389-Directory/1.3.4.0 B2015.343.1254 starting up
- WARNING: changelog: entry cache size 2097152B is less than db size 4259840B; 
We recommend to increase the entry cache size nsslapd-cachememsize.
schema-compat-plugin - warning: no entries set up under cn=computers, 
cn=compat,dc=unix,dc=co,dc=org,dc=au
schema-compat-plugin - warning: no entries set up under cn=ng, 
cn=compat,dc=unix,dc=co,dc=org,dc=au
schema-compat-plugin - warning: no entries set up under 

Re: [Freeipa-users] Importing from shadow: ERROR: Constraint violation: pre-hashed passwords are not valid

2016-01-06 Thread Simpson Lachlan
> -Original Message-
> From: Alexander Bokovoy [mailto:aboko...@redhat.com]
> 

> >When I execute this, I get this error for every entry: "ipa: ERROR:
> >Constraint violation: pre-hashed passwords are not valid"
> >
> >What have I done wrong?
> Did you enable migration mode? The check in the password plugin is conditioned
> on allowing pre-hashed passwords only when the migration mode is on.


Well that's embarrassing. It's even right there, on the page I quoted. Didn't 
even see that paragraph when I was reading it. 

Thank you
L.  


This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been 
intercepted or altered and will not be liable for any delay 
in its receipt.


-- 
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] Importing from shadow: ERROR: Constraint violation: pre-hashed passwords are not valid

2016-01-05 Thread Simpson Lachlan
Hi,

New install of FreeIPA 4.2.0-15.el7.centos.3 on Centos 7.2.1511 (and I'm very 
new to FreeIPA)

Following the advice I got from here: 
http://www.freeipa.org/page/NIS_accounts_migration_preserving_Passwords

I dumped old shadow into a csv, then wrote a small bash script to import all 
the users:

#!/bin/bash
INPUT=s.csv
IFS=,

kinit admin

[ ! -f $INPUT ] && { echo "$INPUT file not found"; exit 99; }
while read lname pw
do

echo "Importing user $lname"
FIRST=${lname:0:1}
LAST=${lname:1}

ipa user-add $lname --first $FIRST --last $LAST --setattr 
userpassword={crypt}"$pw"


done < $INPUT

When I execute this, I get this error for every entry: "ipa: ERROR: Constraint 
violation: pre-hashed passwords are not valid"

What have I done wrong?

Cheers
L.

This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been 
intercepted or altered and will not be liable for any delay 
in its receipt.


-- 
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