[Freeipa-users] AD password synchronization
How can I create the id=passsync,cn=sysaccounts,cn=etc,dc=example,dc=com account without creating a replication agreement. I do not want to replicate accounts between AD and ipa, but I do want password changes on AD to be sent to ipa. Is this possible? thanks, Bob H ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] AD password synchronization
Bob wrote: How can I create the id=passsync,cn=sysaccounts,cn=etc,dc=example,dc=com account without creating a replication agreement. I do not want to replicate accounts between AD and ipa, but I do want password changes on AD to be sent to ipa. Is this possible? # ldapmodify -D cn=directory manager -w secret -p 389 -h ipaserver.example.com -x -a dn: uid=passsync,cn=sysaccounts,cn=etc,dc=example,dc=com objectClass: account objectClass: simplesecurityobject objectClass: top uid: passsync userPassword: secretpassword As for how well this will work, I'm not sure. You'll also need to add this to the pass sync managers entry ala https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/pass-sync.html I forget the details on how the PassSync service links the AD entry to the 389-ds entry. You may need to add additional attributes to IPA for each user you want to keep synchronized. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] local root can su to any IPA user
On Wed, Feb 26, 2014 at 04:24:54PM -0500, Steve Dainard wrote: Would it not be possible for root to disable selinux enforcement? Normally yes, if you're root, you can do all kinds of stuff including appending 'selinux=0' to the kernel command line. Maybe there are better SELinux experts on the list, but if you need to partition the power of root further, maybe MLS SELinux configuration is what you need? A user could maybe even use a livecd if root couldn't be gained directly. Can you protect the bootloader with a password? btw if malicious users have physical access to the hardware, then you're in a difficult situation anyway.. I'm looking at joining workstations to an idm realm, but some users will need sudo permissions on their machines. Do they need the full sudo permissions (to become root) ? Can you just give them permissions to run specific commands (ie /sbin/service etc) ? Is there any documentation on best practices here? Has there been any further discussion on the best way to approach this problem? Thanks, *Steve Dainard * IT Infrastructure Manager Miovision http://miovision.com/ | *Rethink Traffic* *Blog http://miovision.com/blog | **LinkedIn https://www.linkedin.com/company/miovision-technologies | Twitter https://twitter.com/miovision | Facebook https://www.facebook.com/miovision* -- Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON, Canada | N2C 1L3 This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. On Fri, Nov 29, 2013 at 9:41 AM, Martin Kosek mko...@redhat.com wrote: On 11/29/2013 03:17 PM, Jakub Hrozek wrote: On Fri, Nov 29, 2013 at 03:08:44PM +0100, Fred van Zwieten wrote: Jakub, Yes, I could do this. But then the local root account cannot su to local users (without password). But that is actually a normal use-case. I just think local root should not be allowed to transition to a domain user, by default. Fred Ah, in that case I'm not sure if there's an easy solution, at least I don't know any off hand. I think Alexander is right that SELinux would be a good choice. Right. Root could uncomment the pam_rootok.so line anyway if he wanted to access other user's account again. Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] local root can su to any IPA user
On Wed, Feb 26, 2014 at 04:24:54PM -0500, Steve Dainard wrote: Would it not be possible for root to disable selinux enforcement? It should also be possible to copy private keys out of ~user/.ssh and login to other machines as user, assuming no password on the ssh key pair. It's probably best to assume that all your client machines are under the control of knowledgeable, malicious admins, and to put your important information somewhere other than your client machines. The only real way to take back the night is to force your users to connect to a service you control using an authentication mechanism you control. (e.g., Kerberos service tickets: accept no substitute. :) ) Prohibiting them from making any changes makes you responsible for every last customization. Delegating frees you up, but requires trust. Probably a good rule of thumb is to be generous doling out permissions when only one person will ever use the machine. Giving someone control over someone else's workspace should require consent of the controlled. One thing that is nagging at me: I read that sssd caches your credentials in a form such that they can be retrieved and provided to your organizational system. [1] This seems like a vector for a knowledgeable, malicious admin to break out of the client machine and impersonate someone else to any domain service. Is there a safeguard against this? Bryce [1] https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/SSSD.html This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] local root can su to any IPA user
On 02/27/2014 04:03 PM, Nordgren, Bryce L -FS wrote: On Wed, Feb 26, 2014 at 04:24:54PM -0500, Steve Dainard wrote: Would it not be possible for root to disable selinux enforcement? It should also be possible to copy private keys out of ~user/.ssh and login to other machines as user, assuming no password on the ssh key pair. It's probably best to assume that all your client machines are under the control of knowledgeable, malicious admins, and to put your important information somewhere other than your client machines. The only real way to take back the night is to force your users to connect to a service you control using an authentication mechanism you control. (e.g., Kerberos service tickets: accept no substitute. :) ) Prohibiting them from making any changes makes you responsible for every last customization. Delegating frees you up, but requires trust. Probably a good rule of thumb is to be generous doling out permissions when only one person will ever use the machine. Giving someone control over someone else's workspace should require consent of the controlled. One thing that is nagging at me: I read that sssd caches your credentials in a form such that they can be retrieved and provided to your organizational system. [1] This seems like a vector for a knowledgeable, malicious admin to break out of the client machine and impersonate someone else to any domain service. Is there a safeguard against this? SSSD will do catching and storing password only if configured and if the system can't connect to the central server so potentially a bad root admin can configure SSSD to store passwords and then lure other users to connect to the box and while the box is not connected to the central server passwords will be local and root would be able to steal them and impersonate uses. But I would argue that in this case root can just add some other module to the pam stack that would dump passwords for any user who uses pam stack regardless whether SSSD is in the picture or not so it is not SSSD problem and I do not think it can be generally solved with the software. It is the point where you cross the line into physical security and organization's security and trust policies. Bryce [1] https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/SSSD.html This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] winsync and new users
Hi, I have successfully completed agreement between Windows and IPA and it works. When I create user in Windows, it's synchronized to IPA and when I change something on IPA for this user, it's synchronized back to Windows, but when I create *new* user in IPA it's not synchronized (created) in Windows. Is this the way how it's supposed to work? New user are synchronized only from Windows to IPA? Thanks for your reply. Michal ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] winsync and new users
On 02/27/2014 05:01 PM, Michal Zacek wrote: Hi, I have successfully completed agreement between Windows and IPA and it works. When I create user in Windows, it's synchronized to IPA and when I change something on IPA for this user, it's synchronized back to Windows, but when I create *new* user in IPA it's not synchronized (created) in Windows. Is this the way how it's supposed to work? New user are synchronized only from Windows to IPA? Thanks for your reply. Yes. It is a one way sync. Michal ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] winsync and new users
On Thu, 27 Feb 2014, Michal Zacek wrote: Hi, I have successfully completed agreement between Windows and IPA and it works. When I create user in Windows, it's synchronized to IPA and when I change something on IPA for this user, it's synchronized back to Windows, but when I create *new* user in IPA it's not synchronized (created) in Windows. Is this the way how it's supposed to work? New user are synchronized only from Windows to IPA? Yes, that's how it is supposed to work. -- / Alexander Bokovoy ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] local root can su to any IPA user
But I would argue that in this case root can just add some other module to the pam stack that would dump passwords for any user who uses pam stack regardless whether SSSD is in the picture or not so it is not SSSD problem and I do not think it can be generally solved with the software. It is the point where you cross the line into physical security and organization's security and trust policies. In a Kerberos/IdM/AD environment, the password isn't available except at initial sign on. If I sign on using my machine, then ssh to user Evil's machine, the worst user Evil can do is steal my TGT, which has a much shorter life than a password. If Evil is quick, he can get at my files on the main server. But I never give my password to user Evil in this situation, and user Evil is not an admin on my box, where he can affect the pam stack. Thinking this through...This is definitely not a physical security thing: the machine was issued to user Evil and Evil must have physical access to it. These factors are not amenable to change. The problem is that risk and granting power are two sides of the same coin. The challenge is to grant useful amounts of power while mitigating risk to others. For instance: the above description suggests that one way to mitigate risk is to not delegate administrative control over machines which handle other people's passwords. Whether this is policy or just good practice is perhaps a matter of semantics. Either way: Training the users to do the initial signon on their own box will go a long way to eliminating the need for a technical control...Definitely not a software problem... This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] local root can su to any IPA user
On Thu, Feb 27, 2014 at 09:03:35PM +, Nordgren, Bryce L -FS wrote: On Wed, Feb 26, 2014 at 04:24:54PM -0500, Steve Dainard wrote: Would it not be possible for root to disable selinux enforcement? It should also be possible to copy private keys out of ~user/.ssh and login to other machines as user, assuming no password on the ssh key pair. It's probably best to assume that all your client machines are under the control of knowledgeable, malicious admins, and to put your important information somewhere other than your client machines. The only real way to take back the night is to force your users to connect to a service you control using an authentication mechanism you control. (e.g., Kerberos service tickets: accept no substitute. :) ) Prohibiting them from making any changes makes you responsible for every last customization. Delegating frees you up, but requires trust. Probably a good rule of thumb is to be generous doling out permissions when only one person will ever use the machine. Giving someone control over someone else's workspace should require consent of the controlled. One thing that is nagging at me: I read that sssd caches your credentials in a form such that they can be retrieved and provided to your organizational system. [1] This seems like a vector for a knowledgeable, malicious admin to break out of the client machine and impersonate someone else to any domain service. Is there a safeguard against this? Caching credentials is disabled by default[1]. Even when credential caching is enabled, the cache is only ever readable by root, the hashes are *never* exposed to the system. FYI, the hash is a salted sha512. What leads you to believe the cached credentials can be retrieved? [1] in sssd upstream. ipa-client-install enables caching credentials. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] local root can su to any IPA user
On Thu, Feb 27, 2014 at 10:36:01PM +, Nordgren, Bryce L -FS wrote: But I would argue that in this case root can just add some other module to the pam stack that would dump passwords for any user who uses pam stack regardless whether SSSD is in the picture or not so it is not SSSD problem and I do not think it can be generally solved with the software. It is the point where you cross the line into physical security and organization's security and trust policies. In a Kerberos/IdM/AD environment, the password isn't available except at initial sign on. If I sign on using my machine, then ssh to user Evil's machine, the worst user Evil can do is steal my TGT, which has a much shorter life than a password. If Evil is quick, he can get at my files on the main server. But I never give my password to user Evil in this situation, and user Evil is not an admin on my box, where he can affect the pam stack. Assuming you're using the TGT (acquired on your machine) to SSH to Evil, it's still the same case and the SSSD is not even involved. If you're typing your Kerberos password to a machine controlled by Evil, you have problems :-) But that's true with or without SSSD. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] How to restore an IPA Replica when the CSN number generator has moved impossibly far into the future or past
On 02/03/2014 10:37 PM, JR Aquino
wrote:
If you are seeing clock skew errors in
/var/log/dirsrv/slapd-EXAMPLE-COM/errors that look like this, then
you will need to verify the time/date of the server to make sure
NTP isn't freaked out. If the system date is correct, it is
possible that the change number generator has skewed.
Thanks much JR! I have wiki-fied this email
http://port389.org/wiki/Howto:Fix_and_Reset_Time_Skew
I would like to credit you on the page - how would you like to be
attributed?
[01/Feb/2014:14:42:06 -0800] NSMMReplicationPlugin - conn=12949
op=7 repl="dc=example,dc=com": Excessive clock skew from supplier
RUV
[01/Feb/2014:14:42:06 -0800] - csngen_adjust_time: adjustment
limit exceeded; value - 1448518, limit - 86400
[01/Feb/2014:14:42:06 -0800] - CSN generator's state:
[01/Feb/2014:14:42:06 -0800] - replica id: 115
[01/Feb/2014:14:42:06 -0800] - sampled time: 1391294526
[01/Feb/2014:14:42:06 -0800] - local offset: 0
[01/Feb/2014:14:42:06 -0800] - remote offset: 0
[01/Feb/2014:14:42:06 -0800] - sequence number: 55067
The following NsState_Script should be used to determine whether
the change number generator has jumped significantly from the real
time/date.
https://github.com/richm/scripts/blob/master/readNsState.py
The usage for the script works like this:
[r...@ipaserver.ops jaquino]# ./readNsState.py
/etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif
nsState is
cwBGPfBSAQACAA==
Little Endian
For replica cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping
tree,cn=config
fmtstr=[H6x3QH6x]
size=40
len of nsstate is 40
CSN generator state:
Replica ID : 115
Sampled Time : 1391476038
Gen as csn : 52f03d4600020115
Time as str : Mon Feb 3 17:07:18 2014
Local Offset : 0
Remote Offset : 1
Seq. num : 2
System time : Mon Feb 3 17:09:11 2014
Diff in sec. : 113
Day:sec diff : 0:113
If the output from the above command is over a day or more out of
sync, then the reason is because the CSN generator has become
grossly skewed. It will be necessary to perform the following
steps to recover.
How to resolve this issue
• 1: Select an ipa server to be authoritative and write the
contents of its database to an ldif file
On the master supplier:
/var/lib/dirsrv/scripts-EXAMPLE-COM/db2ldif.pl -D
'cn=Directory Manager' -w - -n userRoot -a
/tmp/master-389.ldif
Note that without the -r option it is deliberately ommiting
the tainted replication data which contains the bad CSNs
• 2: On the ipa server, shutdown its dirsrv daemon down so
that you can reset the attribute responsible for the serial
generation, and so that you can re-initialize its db from the
known good ldif
On the master supplier:
ipactl stop
• 3: Sanitize the dse.ldif Configuration File
On the master supplier:
edit the /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif file and
remove the nsState attribute from the replica config entry
You DO NOT want to remove the nsState from: dn: cn=uniqueid
generator,cn=config
The stanza you want to remove the value from is: dn:
cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping
tree,cn=config
The attribute will look like this: nsState::
cwA3QPBSAQABAA==
Delete the entire line
• 3.1: Remove traces of stale CSN tracking in the Replica
Agreements themeselves
File location: /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif
cat dse.ldif | sed -n '1 {h; $ !d}; $ {x; s/\n //g; p}; /^
/ {H; d}; /^ /! {x; s/\n //g; p}' | grep -v nsds50ruv
new.dse.ldif
backup the old dse.ldif and replace it with the new one:
# mv dse.ldif dse.saved.ldif
# mv new.dse.ldif dse.ldif
• 4: Import the data from the known good ldif. This will mark
all the changes with CSNs that match the current time/date
stamps
On the master supplier:
chmod 644 /tmp/master-389.ldif
/var/lib/dirsrv/scripts-EXAMPLE-COM/ldif2db -n userRoot -i
/tmp/master-389.ldif
• 5: Restart the ipa daemons on the master supplier
#ipactl start
