Re: [389-users] Accessing TCP options data in 389ds Hello,
That is true but load balancer iptables see incoming requests as they are. I'm not sure that this is what you need. What information you wish to receive? Besides the real client IP? 12 lip 2013 23:48, "Justin Kinney" napisał(a): > > > > On Fri, Jul 12, 2013 at 2:32 PM, Grzegorz Dwornicki wrote: > >> Are you doing this on loadbalancer? You can use iptables with log target >> but if this is not sufficient, then some kind of sniffer like tcpdump might >> be helpful >> > > The loadbalancer will add the client ip address to the TCP options field > of the client request prior to passing to the servicing node behind the LB. > > >> 12 lip 2013 23:27, "Rich Megginson" napisał(a): >> >> On 07/12/2013 03:25 PM, Justin Kinney wrote: >>> >>> Hello, >>> >>> I'm investigating the possibility of logging client IP address where >>> 389ds is deployed behind a load balancer. Today, we lose the true client IP >>> address as the source IP is replaced with the load balancer's before the >>> packet hits the 389 host. Has anybody solved this issue before? >>> >>> For HTTP based services, this problem is trivial to overcome by >>> grokking the X-Forwarded-For header from the request, but obviously this >>> doesn't work with a service like LDAP deployed behind a TCP based load >>> balancing instance. >>> >>> One option is to use a direct server return (DSR) configuration with >>> our load balancer and host, but that adds a lot of overhead to our >>> environment in terms of configuration complexity, so I'd like to avoid that. >>> >>> Another option is using an interesting capability of our load balancer >>> (and I'm not sure how unique this feature is - I'd be interested in hearing >>> if anyone else has run across it). It can insert the client IP address into >>> the TCP stream, as arbitrary data in the options field of the TCP header. >>> Existence of an address is also indicated by a magic number (which can >>> uniquely identify the VIP on the load balancer). >>> >>> What would it take to modify 389 to access the raw TCP header, parse >>> the options field to get the true client IP, and then associate it with the >>> request? Ideally, the client IP would be accessible in the access log. >>> >>> >>> I don't know - what are the TCP/IP/socket API calls that are required to >>> get this data? >>> >>> >>> Thanks in advance, >>> Justin >>> >>> >>> -- >>> 389 users mailing >>> list389-users@lists.fedoraproject.orghttps://admin.fedoraproject.org/mailman/listinfo/389-users >>> >>> >>> >>> -- >>> 389 users mailing list >>> 389-us...@lists.fedoraproject.org >>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>> >> >> -- >> 389 users mailing list >> 389-us...@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/389-users >> > > > -- > 389 users mailing list > 389-us...@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/389-users > -- 389 users mailing list 389-us...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] Setting up a test server
Are you using Sssd or nscld? 10 kwi 2013 19:51, napisał(a): > > I am trying to implement a "Forgot Password" web page for our organization > and I am at the point where I want to update the user's account with the > temporary password. Since I don't want to have any issues on the > production servers, I have installed a virtual machine with CentOS 6.4 and > have installed 389-ds on it. The server seems to be running (i.e. I can do > an ldapsearch command and see the test users that I have), but I can't seem > to be able to log in as any of those users. > > I have used the Authentication GUI to set the log in method to LDAP and > have put in the required information, but if I try to "su" over as one of > those users, or log out and try to enter one of the test user names, I get > an error saying that the user was not found. > > So, how can I configure CentOS 6.4 to allow access to the test 389-ds > server? > > Thanks, > Harry > > Harry Devine > Common ARTS Software Development > AJM-245 > (609)485-4218 > harry.dev...@faa.gov > -- > 389 users mailing list > 389-us...@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/389-users > -- 389 users mailing list 389-us...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] StartTLS error
https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Configuring_Logs.html Please look in this doc and increase the log verbosity. This might help. 10 kwi 2013 13:15, "alexandre" napisał(a): > Hi, > > I'm having problem with my multi-master replication. > > I have on 389DS server in multi-master replication with a Windows DC > (everything work fine). > > I try to put another 389DS in multi-master replication over startTLS (just > to have redundancy). > > When I do the consumer initialization i've got this error: > > The consumer initializatiion has unsuccessfully completed. The error > received by the replica is: -11 - System error. > > When I go to the /var/log/dirsrv/slapd-389ds/errors: > > slapi_ldap_bind - Error: could not send startTLS request: error -11 > (Connect error) > > > > Just an indication, I went in "manage certificate" on both 389DS server > and I put the server cert and the CA cert, do I miss something ? > > Thanks, > Alex > > > -- > 389 users mailing list > 389-us...@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/389-users > -- 389 users mailing list 389-us...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] Certificate between 389DS and Active Directory
Yes and that button allows you to install server cert (again generated in your case on AD CA) . CA tab allows you to install CA cert. Greg. 27 mar 2013 16:33, "alexandre" napisał(a): > Sorry my capture is not on the mail, it's the point 12.2.1. 4.c.Go to > the *CA Certs* tab, and click *Install* at the bottom of the window. > On this link: > https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Windows_Sync-Configuring_Windows_Sync.html > > Thanks > > > 2013/3/27 alexandre > >> Thanks for the new Link ! >> >> @Rich Megginson"It's not the 389DS server certificate, but the CA >> certificate for the CA that issued the 389DS server certificate, that you >> need for PassSync" >> >> @Grzegorz Dwornicki "But you must generate cert for DS on AD CA. Then >> you need to import this cert with AD CA cert on DS" >> >> Sorry I don't understand "CA certificate for the CA that issued the 389DS >> server certificate", I have to export this one below to the AD? (it's empty >> on this capture, but with CA certificate on my directory server): >> >> >> >> @Grzegorz Dwornicki --> do you have a procedure to do that ? I don't >> find in redhat documentation. (when you said AD CA, do you consider that >> AD CA = Authority installed on my AD ?) >> >> Many thanks, for your answers. And your patience about my translation >> problems. >> >> Best regards, >> Alex >> >> >> >> >> 2013/3/27 Grzegorz Dwornicki >> >>> I had missunderstood you im this case. No you don't need to create >>> second CA. But you must generate cert for DS on AD CA. Then you need to >>> import this cert with AD CA cert on DS >>> >>> Greg. >>> 27 mar 2013 15:41, "alexandre" napisał(a): >>> >>> I'm really impressed by the reactivity of this list !!! >>>> >>>> Sorry my understanding is not perfect because i'm french, so I don't >>>> have any CA in my DS, I have one CA (installed on my domain controller). >>>> >>>> Do I need to install a CA in my DS ? (when I write CA for me it means a >>>> Authority). >>>> >>>> >>>> Alex >>>> >>>> >>>> 2013/3/27 Grzegorz Dwornicki >>>> >>>>> If you have diferent CA in AD vs DS then you need to do this import. >>>>> >>>>> AD by default don't use LDAPS or STARTSSL soo you need to install ms >>>>> cert CA stuff. >>>>> >>>>> Greg. >>>>> 27 mar 2013 15:07, "alexandre" napisał(a): >>>>> >>>>>> Hello, >>>>>> >>>>>> I try to follow this procedure : >>>>>> >>>>>> >>>>>> https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Windows_Sync-Configuring_Windows_Sync.html >>>>>> >>>>>> Everything works fine, except I don't understand right this line: >>>>>> >>>>>> "Import the CA certificate from Directory Server into Active >>>>>> Directory. Click *Trusted Root CA*, then *Import*, and browse for >>>>>> the Directory Server CA certificate." >>>>>> >>>>>> For me CA certificate, it's a certificate from the Authority, so in >>>>>> my Active Directory the certificate from the authority is already know in >>>>>> the Trusted Root CA. >>>>>> >>>>>> So, do I need to import 389DS server certificate in my active >>>>>> directory ? >>>>>> >>>>>> And finally, there is no indication to do that, someone can help me >>>>>> to pass through ? >>>>>> >>>>>> Thanks in advance. >>>>>> >>>>>> Best regards, >>>>>> Alex >>>>>> >>>>>> -- >>>>>> 389 users mailing list >>>>>> 389-us...@lists.fedoraproject.org >>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>>>>> >>>>> >>>>> -- >>>>> 389 users mailing list >>>>> 389-us...@lists.fedoraproject.org >>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>>>> >>>> >>>> >>>> -- >>>> 389 users mailing list >>>> 389-us...@lists.fedoraproject.org >>>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>>> >>> >>> -- >>> 389 users mailing list >>> 389-us...@lists.fedoraproject.org >>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>> >> >> > > -- > 389 users mailing list > 389-us...@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/389-users > -- 389 users mailing list 389-us...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] dirsrv won't start
Sorry I did not see the last time that error is in schema. I don't know how you did it but you break it. You don't need to panic. Because when you install a dirsrv instance the setup script copies the schema from somewhere... I don't remember from where... it was somewhere in /var or /usr... here are some ideas to get the good copy: - Red Hat docs will have this info also you can use find command to find this file. - Installing other dirsrv instance for a moment will create a good copy of this file in its directory. There can be many dirsrv servers on the system. You need to specify diferent port and DN. - you can read setup-ds and find from where it copies schema files. I'm traweling at the moment and I cannot give you more details at the moment. I am writing from my phone. I hope this will help. Greg. 11 sty 2013 21:06, "Doug Tucker" napisał(a): > I was excited to see this reply, thanks so much. Unfortunately, I copied > that to the dse.ldif and the results are the same. It won't start and with > the same error. > > Sincerely, > > Doug Tucker > > On 01/11/2013 11:14 AM, Grzegorz Dwornicki wrote: > >> >> For the record dirsrv creates file in its directory with the last good >> configuration. I believe it was called dse.ldif.startok >> >> Greg. >> >> 11 sty 2013 18:06, "Chandan Kumar" > chandank.kumar@gmail.**com >> napisał(a): >> >> You may not need to re-install it. If you could just replace the >> file that you changed, I hope you took a backup before >> experimenting with the file. Same thing happened with me too, I >> restored the directory server from the bakcup files. >> >> On Friday, January 11, 2013, Doug Tucker wrote: >> >> Well, I give up. I can find nothing in the docs or on google >> to get me around this. I'm see no way other than to uninstall >> 389 and reinstall from scatch so no need to respond to this. >> >> Sincerely, >> >> Doug Tucker >> >> On 01/10/2013 11:19 AM, Doug Tucker wrote: >> >> So I've gone from bad to worse. Googling and googling and >> no response on my auth issue from the list yesterday, I >> coudn't stand doing nothing. The only thing I saw that >> made me curious was some thread where a guy could not auth >> and he changed the password hash to something else and it >> worked. I looked at our current password hash in openldap >> and it was ssha. For the life of me I could not find how >> to see what the current one was in 389. The only thing I >> could find in the docs was how to set a password policy >> which allowed you to set the hash. So I did so according >> to the documentation on the Users cn. The only thing I >> did was turn it on, and make sure password hash was set to >> ssha. I left the rest default which was no expiration, >> etc. I saved, and tried to restart according to the docs, >> it woudn't restart. I shut down with the init script >> instead, and tried to start, and now I get this: >> >> [root@lyleauth1 schema]# /etc/init.d/dirsrv start >> Starting dirsrv: >> lyleauth1...[09/Jan/2013:16:**23:05 -0600] >> dse_read_one_file - The entry cn=schema in file >> /etc/dirsrv/slapd-lyleauth1/**schema/99user.ldif (lineno: 1) >> is invalid, error code 21 (Invalid syntax) - attribute >> type olcOverlay: Missing parent attribute syntax OID >> [09/Jan/2013:16:23:05 -0600] dse - Please edit the file to >> correct the reported problems and then restart the server. >> [FAILED] >> *** Warning: 1 instance(s) failed to start >> >> Looking at the time stamp on that file, it is: Dec 20 >> 16:36 99user.ldif . So what I did yesterday did not touch >> it. Anyone have any idea how to fix this? >> >> >> -- >> 389 users mailing list >> >> 389-users@lists.fedoraproject.**org<389-us...@lists.fedoraproject.org> >> >> https://admin.fedoraproject.**org/mailman/listinfo/389-users<https://admin.fedoraproject.org/mailman/listinfo/389-users> >> >> >> >> -- >> -- >> http://about.me/chandank >> >> >> -- >> 389 users mailing list >>
Re: [389-users] help
I did not get your problem. Can you repeat your mail? Greg. 1 paź 2012 11:52, "Bernd Sindlinger" napisał(a): > > > > > -- > 389 users mailing list > 389-us...@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-us...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] Start TLS and 389 Directory
There is definetly something wrong with your CA. Error is fatal and named
unknown CA. I agree with you now: please try put FQDN in CN field. This
still maybe not the issue but when you create CA cert again then maybe
error will disapear. I usually use openssl to create certs instead of
certutil soo i don't know if you will need to create every cert using shell
script.
Greg.
28 wrz 2012 18:24, "Kyle Flavin" napisał(a):
> Here's the output from ldapsearch (I sanitized the domains). Note that
> for the cacert I used "ROOT CA" for the CN of the certificate. I guess the
> next step is to try to set this to the hostname of ldap01?
>
>
>
>
>
> root@ldap02 ~]# cat /etc/openldap/ldap.conf
> #
> # LDAP Defaults
> #
>
> # See ldap.conf(5) for details
> # This file should be world readable but not world writable.
>
> #BASE dc=example, dc=com
> #URIldap://ldap.example.com ldap://ldap-master.example.com:666
>
> #SIZELIMIT 12
> #TIMELIMIT 15
> #DEREF never
> #URI ldap://127.0.0.1/
> #BASE dc=example,dc=com
> #TLS_CACERTDIR /etc/openldap/cacerts
> TLS_CACERTDIR /tmp/ldap/certs
> #TLS_REQCERT never
>
>
>
>
>
>
>
> [root@ldap02 ldap]# ldapsearch -x -h ldap01..com -D
> "cn=Directory Manager" -W -b "dc=mydomain,dc=com" -d 1 -ZZ ""
> ldap_create
> ldap_url_parse_ext(ldap://ldap01.mydomain.com)
> ldap_extended_operation_s
> ldap_extended_operation
> ldap_send_initial_request
> ldap_new_connection 1 1 0
> ldap_int_open_connection
> ldap_connect_to_host: TCP ldap01.mydomain.com:389
> ldap_new_socket: 3
> ldap_prepare_socket: 3
> ldap_connect_to_host: Trying 10.163.121.194:389
> ldap_connect_timeout: fd: 3 tm: -1 async: 0
> ldap_open_defconn: successful
> ldap_send_server_request
> ber_scanf fmt ({it) ber:
> ber_scanf fmt ({) ber:
> ber_flush: 31 bytes to sd 3
> ldap_result ld 0x14890770 msgid 1
> wait4msg ld 0x14890770 msgid 1 (infinite timeout)
> wait4msg continue ld 0x14890770 msgid 1 all 1
> ** ld 0x14890770 Connections:
> * host: ldap01.mydomain.com port: 389 (default)
> refcnt: 2 status: Connected
> last used: Fri Sep 28 09:16:51 2012
>
> ** ld 0x14890770 Outstanding Requests:
> * msgid 1, origid 1, status InProgress
>outstanding referrals 0, parent count 0
> ** ld 0x14890770 Response Queue:
>Empty
> ldap_chkResponseList ld 0x14890770 msgid 1 all 1
> ldap_chkResponseList returns ld 0x14890770 NULL
> ldap_int_select
> read1msg: ld 0x14890770 msgid 1 all 1
> ber_get_next
> ber_get_next: tag 0x30 len 95 contents:
> read1msg: ld 0x14890770 msgid 1 message type extended-result
> ber_scanf fmt ({eaa) ber:
> read1msg: ld 0x14890770 0 new referrals
> read1msg: mark request completed, ld 0x14890770 msgid 1
> request done: ld 0x14890770 msgid 1
> res_errno: 0, res_error: <>, res_matched: <>
> ldap_free_request (origid 1, msgid 1)
> ldap_parse_extended_result
> ber_scanf fmt ({eaa) ber:
> ber_scanf fmt (a) ber:
> ldap_parse_result
> ber_scanf fmt ({iaa) ber:
> ber_scanf fmt (x) ber:
> ber_scanf fmt (}) ber:
> ldap_msgfree
> TLS trace: SSL_connect:before/connect initialization
> TLS trace: SSL_connect:SSLv2/v3 write client hello A
> TLS trace: SSL_connect:SSLv3 read server hello A
> TLS certificate verification: depth: 1, err: 19, subject:
> /C=US/ST=California/L=Burbank/O=mydomain/OU=ADS/CN=ROOT CA, issuer:
> /C=US/ST=California/L=Burbank/O=mydomain/OU=ADS/CN=ROOT CA
> TLS certificate verification: Error, self signed certificate in
> certificate chain
> TLS trace: SSL3 alert write:fatal:unknown CA
> TLS trace: SSL_connect:error in SSLv3 read server certificate B
> TLS trace: SSL_connect:error in SSLv3 read server certificate B
> TLS: can't connect.
> ldap_perror
> ldap_start_tls: Connect error (-11)
> additional info: error:14090086:SSL
> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
>
>
>
> On Fri, Sep 28, 2012 at 8:46 AM, Grzegorz Dwornicki wrote:
>
>> I was thinking about server cert but I usually put fqdn in every
>> certificate I made.
>>
>> This is intersting problem. Can you provide output of ldapsearch with
>> debug plus contents of /etc/openldap/ldap.conf?
>>
>> Greg.
>> 28 wrz 2012 17:20, "Kyle Flavin" napisał(a):
>>
>> I tried both tls_cacert and tls_cacertdir, same resul
Re: [389-users] Referral (10) (what does it mean)
What configuration you have? Is this repliction schema? Or maybe linked ldap tree build from many severs? This message looks to me like you are trying to modify a slave replication server ldap tree. I can be wrong. Greg. Send from htc desire z 13-08-2012 16:29, "Fosiul Alam" napisał(a): > hi All > > When i try to Delete a user from groups.. i get bellow > > > ldapmodify -v -xZZ -D "cn=Directory Manager" -w 'testtest' -f > get_groups.ldif > > modifying entry "cn=system-users,ou=groups,l=uk,dc=fosiul,dc=lan" > ldap_modify: Referral (10) > matched DN: dc=fosiul, dc=lan > referrals: > ldap://.uk.fosiul.lan:389 > ldap://.us.fosiul.lan:389 > ldap://.za.fosiul.lan:389 > ldap://.us.fosiul.lan:389 > ldap://.us.fosiul.lan:389 > > We have couple of ldap server ( one master , rest slave) > > do i have to define master server?? this is master server > (ldap://.uk.fosiul.lan:389) > > what would be the commands ? > > Thanks > -- > 389 users mailing list > 389-us...@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-us...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
