For some reason my client server is not pulling group information from
the ldap server. "getent passwd" pulls over all the relevant accounts
from the ldap database. "getent group", however, is missing my
personal group. I don't have any entries for my user in /etc/passwd
or /etc/group on the loc
> If you're going to start mixing local and LDAP stuff that way, you're
> going to run into some fun-to-debug strangeness if you're not careful
> about them all being identical.
Thanks again for your help, I have this working now. I had a comma in
my AllowGroups line instead of a space.
We're sl
> I have UsePAM turned on, and getent group shows me in the "operations"
> group. I wonder why sshd is not seeing that I'm in the operations
> group?
Ok, never mind. On this particular server there was one entry in
/etc/group with my username in it, that was somehow interfering. Once
I removed
> For example, we might have a group called "db-ssh" that defines a user
> group allowed to access database servers. Then we just make sure DB
> hosts get "AllowGroups db-ssh" added to their SSH configs. Plopping a
> user into the db-ssh group in LDAP then gives that person access to all
> the bo
> The problem is probably in pam. Lot s of internet docs have incorrect
> info advice and say.
> account required pam_nologin.so
> account sufficient pam_ldap.so
>
> When you do that you get the situation you have now. In some phases of
> login sufficient becomes required.
>
> Try this:
B
> I will try and figure out how to get some console logging going on my
> windows 389 console client, since the Linux one never worked for me
> (the GUI was all messed up with no text on the buttons). I'll post
> the log output here if I can get it.
I got this working, if anyone else needs the so
For those of you with multiple servers that use replication, how do
you do your load balancing and failover? DNS round robin? Some kind
of hardware load balancer like a Netscaler or BigIP F5?
--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listi
> You shouldn't have to import any certs into the console. See
> http://www.redhat.com/docs/manuals/dir-server/8.1/console/Starting_the_Server_with_SSL_Enabled-Enabling_SSL_in_the_DS_Admin_Server_and_Console.html
Step 2 says "Obtain and install server and CA certificates on the
Administration Ser
> #man authconfig
>
> And you will see there is one option shown below:
>
> --enablemkhomedir create home directories for users on their first login
>
> Just use this option to create the home directory.
Odd, this option was not on my manpage. And it didn't work on one of
my servers. I have
>> Is the process of importing a cert for the admin console the same as
>> the one for the directory server? They both have cert8.db and key3.db
>> files. But that is how I locked myself out the first time I tried!
>>
> I'm not sure what happened - configuring TLS/SSL using the console is
> trick
My LDAP server is working well, but at this point we're not ready to
make the jump over to LDAP-only authentication. I would like to keep
regular shadow passwords working for a while. I have run
authconfig-tui on one of the CentOS clients and made sure "Use MD5
passwords", "Use Shadow Passwords",
> If you have previously run the console using TLS/SSL, and the CA cert
> has changed, it is usually a simple matter of doing rm -rf
> ~/.398-console and running console again.
Is the process of importing a cert for the admin console the same as
the one for the directory server? They both have ce
>> Any suggestions for migrating accounts from /etc/shadow into the LDAP
>> database? I tried this LdapImport perl script but it threw a bunch of
>> errors and ultimately failed:
>
> At the time I did the initial import here, I put together a really ugly
> shell script that used a few cuts, greps
> Incidentally, that may also answer your other question about how to
> disable local shadow file passwords.
Any suggestions for migrating accounts from /etc/shadow into the LDAP
database? I tried this LdapImport perl script but it threw a bunch of
errors and ultimately failed:
http://wiki.babel
> /etc/security/access is definitely an option, as would be putting them
> all in a group and using "AllowGroups [your group]" in the sshd_config,
> among other possibilities.
>
> Doing something group-based is typically pretty easy to manage.
Thanks for the info, the sshd_config file may be the w
> #2
> a.there is also a setting in /etc/ldap.conf called pam_groupdn. This
> lets you define an LDAP object with multiple membe attributes to
> control who can login. I find it easy to use
> b. SSH can be told to only accept logins from a posix group (same deal
> just handled at a different part o
Wow, fast reply Muzzol!
>> 2. If there are some users who only need access to a small number of
>> servers, how would you handle that situation?
> modify /etc/security/limits.conf to your needs
What about /etc/security/access? Do you think this is the best way to
accomplish this? Assume that I
> Are you running 389-admin 1.1.10?
This is what I have installed, all from the yum repo:
[r...@fds dirsrv]# rpm -qa | grep 389
389-admin-console-1.1.4-1.el5
389-ds-1.1.3-4.el5
389-admin-console-doc-1.1.4-1.el5
389-ds-console-doc-1.2.0-4.el5
389-ds-console-1.2.0-4.el5
389-dsgw-1.1.4-1.el5
389-adm
>> Anyone have a suggestion how to fix this?
>>
> 389-console -D 9 -f console.log - take a look at the console log
Thanks for your reply, Rich. I tried this and simply got another
console window, but no log entries. Is there a way to do this from
the command line instead of the GUI?
--
389 users
I'm attempting to add a user to a new directory that I set up for
testing purposes. I have started fedora-idm-console and logged on
successfully as cn=directory manager, but when I hit the "Create"
button to add a new user, the cursor simply sits there spinning, and
spinning
Anyone have a sug
20 matches
Mail list logo
