On Mon, 2014-05-26 at 09:46 +0000, Longina Przybyszewska wrote: > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Vinícius > Ferrão > Sent: 26. maj 2014 00:57 > To: End-user discussions about the System Security Services Daemon > Subject: Re: [SSSD-users] Login with Enterprise Principal Name with AD backend > > > On May 25, 2014, at 19:51, steve <[email protected]> wrote: > > > On Sun, 2014-05-25 at 22:31 +0000, Vinícius Ferrão wrote: > >> Hello guys, > >> > >> I’m running sssd version 1.11 in Ubuntu 14.04 LTS (1.11.5-1ubuntu3) to > >> authenticate users from Active Directory from WIndows Server 2012 R2, and > >> I’m trying to achieve logins with the User Principal Name for all users of > >> the domain. But the UPN are always Enterprise Principal Names. > >> > >> Let-me illustrate the problem with my user account: > >> > >> Domain: local.example.com > >> sAMAccountName: ferrao > >> UPN: [email protected] (there’s no local in the UPN) > >> > >> I can successfully login with the sAMAccount atribute, which is fine, but > >> I can’t login with [email protected] which is my UPN. The optimum > >> solution for me is to allow logins from sAMAccount and the UPN. If’s not > >> possible, the UPN should be the right way instead of the sAMAccountName. > >> > >> Another annoyance is the homedir pattern with those options in sssd.conf: > >> default_shell = /bin/bash > >> fallback_homedir = /home/%d/%u > >> > >> What I would like to achieve is separated home directories from the EPN. > >> For example: > >> > >> /home/example.com/user > >> /home/whatever.example.com/user > >> > >> But with this pattern I can’t map the way I would like to do. > >> > >> I’ve looked through man pages and was unable to find any answers for this > >> issues. > >> > >> Thanks in advance, > >> Vinícius. > > > > Hi > > Not sure about the accountname bit but the 2012 schema has full > > support for rfc2307 out of the box. Store whatever home directory you > > like on a per user basis under their DN as: > > uinixHomeDirectory > > Likewise: > > loginShell > > with whatever shell they need. > > The 1.11.5 ad backend will automatically grab them with no further > > configuration needed. > > Steve > > Hello Steve, thank you for the fast reply. I was aware of the AD ldap schema. > > I’m avoiding to mess with Unix specific atributes inside AD because Microsoft > started the decommissioning of Unix Services. Today still exists hacks to > enable the UNIX Attributes tab in the User Preferences, but they can only be > enabled activating Services for NIS from the Powershell. > > I know it’s an option, but the whole point of using SSSD is to avoid messing > with AD. If it’s impossible to achieve in the SSSD side, that will be the > solution for the second issue. > > Thank you, > Vinícius. > > Hi there, > So what is the scenario for minimal possible AD mess - do not use at all > Posix Attributes? > If we don't plan to use Nis services, but need Posix schema and Posix > attributes for searching uid/gid /autofs maps- are we not safe? > It is important decision for our project, as we are just about to ask for > "messing AD" by attaching gid number for existing AD groups and keep gid > number assigning for all groups created in the future. > It seems to be the rightest way to achieve unique uid/gid on the Linux > clients, as we have different kind of storage (Sun storage) often with own > algorithm of resolving Uids&group id from SID in AD forest with trusted > domains. > I even don't know how much mess is it with assigning gid number to all AD > groups - is it just a piece of cake which MS admins would love? ;( > > What could be the safe concept (not IPA yet ) for AD Linux integration with > sssd to be on the safe side against MS decommissioning of Unix Services ?
Hi You do not need sfu to use posix attributes in AD. HTH Steve _______________________________________________ sssd-users mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/sssd-users
